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)
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.
Bug 20157436
Change-Id: I2eb030a24efdd466a2eee1666c5231201b43684b
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
In a new split system user model, owner of a restricted profile is not limited
to just user0. restrictedProfileParentId field should be used to get an owner.
Bug: 22950929
Change-Id: I928319a9450e543972237a42267eb2404e117c83
The version of ConnectivityService.java in mnc-vt-dev doesn't
compile due to the presence of two similar-but-not-identical code
blocks in handleRegisterNetworkAgent. The history here is a
a little convoluted - this code was originally merged into
mnc-vt-dev, then cherry-picked into dr-dev, and from there
automerged into mnc-vt-dev, causing conflicts. This latest
breakage is likely due to the automerged not detecting a conflict
because the code block was subtly different.
Attempt to fix this once and for all by making the mnc-vt-dev
version of the file identical to the mnc-dr-dev version.
Change-Id: I270739b0be6f6358045700494a1b0f25f0b365a3
1. When registering a NetworkCallback, only update RSSI
thresholds if the request specifies a signal strength.
2. When releasing a NetworkCallback, only update RSSI
thresholds if the request specified a signal strength.
3. Add logging.
Add logging.
Bug: 21405941
Bug: 23679346
Bug: 23815756
Change-Id: I4bc42d0ab02285a7a9d14e09f8a1cd868f4d9d7f
