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
Requests without NET_CAPABILITIES_INTERNET and just the default network
capabilities should not be marked restricted. Without this fix apps
can hit permissions exceptions if they inadvertently make requests
without NET_CAPABILITIES_INTERNET.
Bug:23164917
Change-Id: I4c7136821315bcb05dfc42ffbc505a5d4f6109e6
This isn't specific to work profile. When multiple user
deletions happen in sequence, a race causes a dying user
to lose permissions prematurely. This fix delays removal of
user state until the user is completely cleaned up and all the
processes have been killed.
Bug: 23178833
Change-Id: I1636bc2022416359a25f19a3f65d113c05289cd3
LTE radios take 10 seconds to power down, so we should set the
activity timeout to 10 seconds.
Bug:23294704
Change-Id: I7478b77f134b0fe2d82e39acd5c370add12735ca
This fixes an issue where a window state animator holds on to old clip
rect from previous transition and applies it to the newly created surface.
Bug: 22851074
Change-Id: Ic416a2a0c5d0f69fc80d5656541256ade41c9c36
This introduces a new phase of device idle mode, immediately
before going idle (once we are sure the device is not moving),
try to collect a location for the device so that any later
requests for it will have a good chance of having an accurate
value.
We do this with two location requests: one a single-shot as
accurate as possible location, and a second longer-running
attempt to get an accurate location from the GPS. There is
a limit on how long we will try to collect the location (default
is 30 seconds), and we stop collection once we reach a desired
accuracy (default is 20 meters).
Also cleanup various transition paths out of the normal state
flow to clean up any active state we may have running.
Change-Id: Ibd3d2e9a720fbfd9640755baf5547180dd409f6a
The target app crashed at an inopportune time but this shouldn't
invalidate the whole ongoing restore operation; it's a problem local to
the specific app undergoing restore. Recognize this, clean up the app's
possibly-incomplete data, and continue running the restore queue as
planned.
Bug 23228982
Change-Id: If9a19d2fe6a0ce5339c893630d7a61a5a5ccd9b1
In particular, don't assume that the absence of an explicit permission
requirement means that the activity is freely launchable unless you have
also checked thing like exported="true" first.
Bug 23223804
Change-Id: Idbfd1f5662b374a7a447b738591b267a1c497e41
...from Camera360 to Hangouts }
In the short URI toString, include a small summary of the ClipData (instead
of just saying it has a clip data). This makes it a lot easier to understand
what is happening when you look at the log of activity starts.
Also separate out the activity manager dump of URI permission grants from
its dump of providers, so it is easy to just look at that state.
Change-Id: I68093d9f279944e1aa9a29347075f237f4f55ed3
..in link-opening behavior. If a candidate is marked as "ask
every time," then the user is guaranteed to get a disambiguation
prompt including that candidate even when some other candidate
app is in the "always prefer this over a browser" state.
Bug 23147746
Change-Id: I904d8697a992b3f16f32b1c1b49c2bf9424c7137
...with protection flag PROTECTION_FLAG_DEVELOPMENT
Bring back the old grant/revoke code for development permissions.
Also some more dumpsys output to help debugging.
And new dumpsys command for checking a permission.
Change-Id: I6e27e62a9ca5ec1ecc0f102714a448ea02f0f41c
The platform grants runtime permissions by default to apps on the
system image that provide core device use cases which a user expects
to work out-of-the-box. We are now adding a test to ensure that
OEMs cannot pregrant premissions on non approved components.
bug:23043018
Change-Id: Id76717cce0ee59678956bd0be347d3c045fe4c51
Global restriction of background data only applies to metered
interfaces, but battery saver applies to all interfaces. In the
very specific case where global background had been turned on while
battery saver was enabled, we'd end up with a stale battery saver
rule floating around.
This change triggers an update of iface rules when the global
restriction changes, giving us consistent behavior.
Bug: 23098198
Change-Id: I454dc71cf11d50a2e9e6122e8a801ff17039b43a
When upgrading from a pre-M version of Android, install permissions for
exisiting system are promoted to runtime permissions. This only happens
for apps that existed prior to the OTA. Other system apps targeting M
are not automatically granted any permissions.
Bug: 22970710
Change-Id: I964ee3f93c66ea43fbb1be6b5ac6b09ddea3c385
This will prevent users from losing their language setting when they
take an OTA to M.
bug: 23021286
Change-Id: Ifb66f6bf6a940ab745edac709321f3009ec6eab4
The timeout for waiting for Keyguard drawn was posted at the wrong
place. If the screen was turning on but the device wasn't waking up,
like in doze mode, we didn't post the timeout, thus, if Keyguard
wouldn't notify us, we would never unblock the screen. This doesn't
really cause a user visible bug but it *could*
prevent the screen from turning on if Keyguard doesn't behave nicely.
Put it at the right place so I can sleep better.
Bug: 21855614
Change-Id: Icda31399261b4ee80c292ce09a0858b0127e2999
Removes overlap from the color views which resulted in subotimal looks
when both color views were translucent and the nav bar was on the right
edge.
Also fixes a bug introduced in I2df7092a91eceeb815367ef917dd7289f4f2b27e
where the navigation-bar-on-right-side case got forgotten and caused
flickering in landscape when IMMERSIVE_STICKY was set but the navigation bar
was visible.
Bug: 22876533
Change-Id: I449a82eb3dc3f7b5051f26b37b362a196b4ff63a
AccountManagerService can't ever synchronize on mUsers within a block of
code locked by UserAccounts.cacheLock. That will lead to deadlocks.
This change fixes a case where we were doing that in
getAccountsInternal(). Also I have purgeOldGrantsAll() run off the the
main thread.
Bug: 23036400
Change-Id: I8634691ca54c57a6e83633baba549226fdcd1064
- In the existing logic, the call to onProvidersChanged() is called when a package
with widgets is added or removed, but only called when a package is updated _and_
there is an app widget bound to a host. This differs from what the expected
behavior is based on the documentation and means that packages with widgets that
update have no way of notifying host apps of changes except via package events.
Bug: 20698931
Change-Id: I60af36d51e99ca1ea751d9d9d03a50ef2d5bef98
