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
... by never rebasing the theme. We don't need to do this unless the
system theme is configuration-dependent, which it is not currently.
Bug: 22943781
Change-Id: I96e695441543379e4d5fdf3cc6f18d9e6cf953b4
If socket initialization fails, DhcpState#exit will call
mReceiveThread#stop and crash the system with an NPE. Make sure
we don't do that if mReceiveThread is null, and properly null it
out when exiting.
Bug: 23088314
Change-Id: I4378d8280f9d8588f5eaa8bd7ade61beab1c3ce2
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
Certain operations (like ConfirmCredential) can be invoked
in the context of a profile, in which case the calling code
needs to know under what profile the credential is registered.
Expose a centralized location for this information for Settings
and GateKeeper to consume.
Bug: 22257554
Change-Id: Iffe4f6a254f52d1269b9287edabcf6efa515d9d2
Now InputMethodManagerService generates the following log
Couldn't create dir.: /data/system/inputmethod
not only when it fails to create the directory but also when
/data/system/inputmethod already exists, which makes it
difficult for us to figure out the root cause of boot failure
on emulator environments (Bug 22857361).
With this CL, IMMS no longer shows the message when the
directory already exists. Basically this is no risk change,
which changes only the condition to show the logging message.
Bug: 22857361
Change-Id: I09aaf501b19845c8309b09b57c23077f1757cd1a
1. Add a missing statement in the parsing code
2. Notify for all packages on UID ap op policy change
bug:22957162
Change-Id: Ic2bd5d07ef52be207e66b63ffe45fd8a456eb5a8
