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
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
Icdad980eec64e081d15679600da07cf4431e40d6 allowed us to
properly return to the home acitvity when a task is moved
to back. However, this improperly moved the home task to
the front if it is the task we are moving to the back on
a single stack device. We now prevent the movement of the
home task to the front from happening.
Bug: 23088310
Change-Id: Ic21779cdb2d2007671d212d41fab5e68be2ae632
BUG: 23086704
Cherry-picked from https://android-review.googlesource.com/#/c/162280/
When the screen goes off or dreaming start, an alarm will be
scheduled and idle state will be true when the alarm expired.
If the screen goes on or dreaming stop happens before
the alarm expired, the alarm isn't cancelled and idle state is
set to be true when the device is in SCREEN_ON or DREADING_STOPPED
state. There is also a case that Idle alarm triggered when
the screen on or dreaming stop just start to be processed.
ACTION_TRIGGER_IDLE will set mIdle to true during screen on
or dreaming stop.
In this patch, the alarm will be cancelled when the screen goes
on or dreaming stop and screen-on flag will be set. So the idle
state can only be set when screen is off or dreaming started.
Change-Id: Ic21a2394418ca55513ab932b3bfad1126b8769c1
This tightens the guarantee that detached stack won't be used. We also
add logging to detecting a situation where a stack not belonging to a
display is being moved on that display.
Bug: 22191609
Change-Id: Ia674bb5960018104a56c5138775ab5216906675b
...to persist after reboot
We were writing a corrupt settings file, so would always reset back
to the default app ops state after boot...!
Also add new appops service commands to manually write and read
its settings, since that is very useful for testing.
Change-Id: Ia510507764738fd82e45ec0be6db840c6ea30c28
We now have a new whitelist you can put apps in, which
opts them out of the old battery saver mode and new app idle,
but doesn't keep them from going in to doze. This is for a few
special cases that we had previously whitelisted for battery saver,
and inherited to the new modes... ultimately we should figure out
how to get these apps out of the whitelist completely, but this
will help for now.
Apps in this new whitelist are not shown in the UI, because they
are still significantly restricted by not being able to operate
normally in doze. This also means they are still visible in the
list of all apps for the user to be able to put them on/off the
complete whitelist if that is what they really want.
In the course of doing this, I needed to clean up code in the
network policy manager to better separate management of the
two firewall rules that now have different whitelists applied
to them. This also hopefully just generally simplifies and cleans
up that code. Hopefully!
Change-Id: I92e15f2f85899571dd8b049b5e3eb1354f55f353
Merge the CHANGE_NETWORK_STATE permission with WRITE_SETTINGS.
AndroidManifest.xml:
Raised the protection level of CHANGE_NETWORK_STATE permission from
normal to signature|appops and pre23|preinstall for compatibility
provider/Settings:
Wrote new helper methods to check if app is allowed to change network
state.
ConnectivityManager.java & ConnectivityService.java:
Replace enforcement checks for CHANGE_NETWORK_STATE with
checkAndNoteChangeNetworkStateOperations instead.
Change-Id: If8c2dd3c76a5324ca43f1d90fa17973216c2bcc5
When creating a work profile, system apps are uninstalled and then
sometimes reinstalled.
In the process, they lose their intent verification status.
BUG:22943461
Change-Id:I5b008c6de2125f190063b08908076a649067c60d
Internal volume was not available during PackageManagerService creation,
which resulted in a zombie user's folder not being cleaned after a reboot.
Add the internal volume earlier in the boot cycle so that it can be accessed
for user cleanup.
Bug: 22483086
Change-Id: I8f3ffbb25f3902d00a96d1ee2d7a79373c5e35b7
1. When a permission is revoked we kill the app immediately but do
not do an immediate kill for shared uid processes. This fixes it.
2. Remove system APIs that are used only by the package installer.
bug:22984670
Change-Id: I3d4ae52ea8679f894aa7c5972941263903479183
It is possible for a tasks not to have been saved to the
persisted recent list yet for various reasons. This causes
some external calls to fail when they are trying to do
an operation on a task with a given id. We now use the
stack supervisor look-up for a task id that checks
everywhere a task might be including live stack. It this
fails then the task truly doesn't exist.
Bug: 22924782
Change-Id: I57c3df41d0b4f3ee3c5ae9b7d01eeb2b352062b4
When lock task mode is started, we verify that the package is
whitelisted and currently use mCallingPackage as indicator. However,
the calling package is not necessarily identical to the package trying
to lock itself, so lock task mode sometimes fails. Switching over to
using realActivity as package marker.
Bug: 22916291
Change-Id: Ifd4df2d634842c8106b0b0f690bcf1faba0ed5fa
In ag/733689, which was intended to fix this bug, the following lines
were removed:
// Propagate the permissions state as we do want to drop on the floor
// runtime permissions. The update permissions method below will take
// care of removing obsolete permissions and grant install permissions.
ps.getPermissionsState().copyFrom(disabledPs.getPermissionsState());
The intent with these lines seemed to be that we needed to copy
permissions from the application on /data, which is being uninstalled,
over to the copy on /system, which was disabled but is being
reenabled. However, it wasn't functional, because it incorrectly
copied from the copy on /system, not the copy on /data.
Restore this code, copying from newPs (the copy on /data) rather than
disbledPs (the copy on /system), and clarify the comment because we do
*not* want to drop runtime permissions on the floor.
Bug: 22665508
Change-Id: I6bae37e70b6df1043c9a2b49255b985707ba151a
When the device is lost or stolen, it's safer to
fall back to strong authentication (pin, pattern or
password). This disables fingerprint like we do with
trust agents.
Fixes bug 21620081
Change-Id: I7bbe54be3721b2f160b783daeb3acbe434705046
