~Rename only (and any reformatting needed to pass lint) - no
functional changes!
Remove android.net.wifi.nan.STATE_CHANGED from manifest:
redundant/remnant of an older configuration.
Bug: 32263750
Test: All unit tests and integration (sl4a) tests pass.
Change-Id: I6866f8825101a32adb9b05d83f0d9d3792b478b7
Add TRANSPORT_WIFI_NAN - specifies a peer-to-peer Wi-Fi NAN data
connectivity request.
While NAN uses Wi-Fi L1 PHY and part of the MAC - it is a different
protocol and constitutes a different transport.
Bug: 26564277
Change-Id: I975ebc72d8f97a592d18038b3d6465b7a40efa75
Listen for ICMP6 router advertisements on networks that support
packet filters. Construct packet filters and install them to
ignore redundant future ICMP6 router advertisements.
Bug: 26238573
Change-Id: If78300b9fda257c21f3ee6533e1da7de9f897cb4
With this it's possible for callers to:
Network network = ...
LinkProperties lp = ...
NetworkDiagnostics netdiag = new NetworkDiagnostics(network, lp, 5000);
netdiag.startMeasurements();
netdiag.waitForMeasurements();
boolean result = true;
for (Measurement m : netdiag.getMeasurements()) {
if (!m.checkSucceeded()) {
result = false;
// Additional error handling here.
}
}
return result;
Bug: 21832299
Bug: 26780890
Change-Id: Iaf7ff029e2c6a998b574c23d0dcde8d57a467a22
1. Unhide MSIM APIs in TelephonyManager that already have non-MSIM equivalent
APIs public.
2. Make MSIM API naming consistent (overloaded, no suffix).
3. Unhide APIs in SubscriptionManager that are necessary for MSIM.
Bug: 26772894
Change-Id: Ibebab7379ea79c8e4812bbd190342827048e30e2
Current usage of NetworkSpecifier: network factory will match a request
if the request has either a (1) empty network specifier, or (2) a
network specifier which is identical to that of the network factory.
Note: 'matching' w.r.t. network specifier - all other matching rules
are still in effect.
Change: add rule (3) or the network specifier of the network factory
is the special string (which is defined as "*" and which user-facing
network requests aren't allowed to use).
Rationale: allows on-demand network creation.
Example:
- Can specify a Wi-Fi NetworkRequest with NetworkSpecifier="ssid"
- It will match a Wi-Fi network factory specifying NetworkSpecifier="*"
- That network factory will bring up a Wi-Fi network, connecting to the
specified SSID.
- Once the network is created it will create a NetworkAgent which will
now have a NetworkSpecifier matching that of the request (not the
match-all special string!)
That final step of making sure that the NetworkAgent matches the request
and not the match-all is critical to delivering any subsequent callbacks
correctly. I.e. your network will only get callbacks which match it.
Bug: 26192833
Change-Id: I49e3b492e0bb48a3f6e9a34e3f94f0e1cf89741f
The Alarm Manager now supports a set() variant that takes a listener
callback to invoke at alarm trigger time rather than a PendingIntent.
This is much lower overhead and has guaranteed low delivery latency
from the trigger time. The tradeoff is that the app must be running
*continuously* from the time the alarm is set to the time it is
delivered. If the app exits for any reason before the alarm fires,
the listener becomes invalid and the alarm will be dropped. This is
more or less equivalent to setting an alarm with a broadcast
PendingIntent that matches only a runtime-registered receiver.
The app's alarm listener can be any object that implements the new
AlarmManager.OnAlarmListener interface and implements its onAlarm()
method. There is no data delivered at alarm trigger time: whatever
state needs to be associated with the specific alarm instance should
simply be packaged inside the OnAlarmListener instance.
An alarm using OnAlarmListener can request that the onAlarm() method
be called on an arbitrary handler. If the program passes 'null' for
this parameter when setting the alarm, the callback occurs on the
application's main Looper thread.
Cherry-picked from a75b36178d
Bug 20157436
Change-Id: I2eb030a24efdd466a2eee1666c5231201b43684b
These framework permission strings were being used as arbitrary labels
that mapped to netd permissions that have completely different meaning.
This leads to confusion, so use different strings.
This is being cherry picked from lmp-mr1-dev to lmp-dev to fix failures
when creating restricted networks due to prior back-port e203d89.
Bug: 21900139
Bug: 18194858
Change-Id: Ib3ec377ab26ce904d3d4678f04edec6cb1260517
(cherry picked from commit d9bf64ba1d)
This is a partial revert of http://ag/738523 , but not a full
revert because M apps that have gone through the WRITE_SETTINGS
route to obtain permission to change network state should
continue to have permission to do so.
Specifically:
1. Change the protection level of CHANGE_NETWORK_STATE back from
"signature|preinstalled|appop|pre23" to "normal". This allows
apps that declare CHANGE_NETWORK_STATE in their manifest to
acquire it, even if they target the M SDK or above.
2. Change the ConnectivityManager permission checks so that they
first check CHANGE_NETWORK_STATE, and then ask Settings
if the app has the WRITE_SETTINGS runtime permission.
3. Slightly simplify the code in the Settings provider code that
deals specifically with the ability to change network state.
4. Make the ConnectivityService permissions checks use the
ConnectivityManager code to avoid code duplication.
5. Update the ConnectivityManager public Javadoc to list both
CHANGE_NETWORK_STATE and WRITE_SETTINGS.
Bug: 21588539
Bug: 23597341
Change-Id: Ic06a26517c95f9ad94183f6d126fd0de45de346e
Play a sound and vibrate (by setting DEFAULT_ALL) only if the
user manually selected the network. This applies to both captive
portals and networks with no Internet access.
Bug: 24126143
Change-Id: Idf075d5c85f9f4b07a3431a25d1a3f7089cf1ee2
This is currently being hit because Settings does not clear the
always-on VPN configuration when the corresponding VPN profile is
deleted. This will be fixed in Settings, but there's no harm in
being robust to invalid configurations here.
Bug: 23625458
Change-Id: Id185a54d5892339197cd40026df5174debd957cf
