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
We generally dispatch while the display is off and we're dozing,
under the assumption that the dozing window is controlling the
display state and wants the events as they come in. Unfortunately,
it's possible that we're dozing but something other than the dozing
component has focus, which leads to dropped and cancelled events.
This was preventing media events from being propogated to the media
session under a number of scenarios, so for now we'll just prevent
dispatching entirely while the display is off and the device is in a
non-interactive state. Going forward we should figure out a better
solution so that doze components can continue to receiving input
events throughout their lifecycle, regardless of the display state.
Bug: 22422588
Change-Id: Ia38bd81245234743e84548841d6478f75a6b8775
When renaming a package during an OTA we were getting in a state
where the package setting mapped to the package UID was not the
same instance as the one we create for the new package mapped.
This leads to a drift between the permissions state for the package
and that state for the UID, resulting in broken for UID permission
checks as granted permissions were never appearing in the per UID
package setting.
bug:22928831
Change-Id: Ib0372632ec84a917304561fd94032cd09bb4c12f
As discussed in b/21429947 (commit
674019065bceb4150190bfb1aa63cda9de0a8560), MTP must always be
enabled, even if access to the underlying MTP data is disabled.
Otherwise, Android will not enumerate on the USB bus, and won't
receive notifications from the kernel about USB state changes. This
effectively prevents using MTP functionality on user builds, or
on userdebug/eng builds with adb turned off.
Always ensure that MTP is the default driver mode.
Move the DISALLOW_USB_FILE_TRANSFER filtering of mUsbDataUnlocked from
setting time to the time we post the sticky broadcast.
Remove isUsbDataUnlocked(). It essentially duplicates data in the sticky
broadcast.
Bug: 22447614
Bug: 21429947
Change-Id: I9d0d94cadbf6db6281ebd77bfb7162f9d06520c2
Temporarily revert ag/735253 until b/22902898 can be resolved with a
proper DMAgent prebuilt drop.
This reverts commit e7ed827a104ba005b93faa2edb3bc77f72b240ec.
Bug: 22902898
With this change:
1. NOT_RESTRICTED should be removed from NetworkRequests that bring up
special restricted carrier networks (e.g. IMS, FOTA).
2. NetworkRequests without NOT_RESTRICTED require CONNECTIVITY_INTERNAL
permission to register
3. Binding sockets to networks without NOT_RESTRICTED requires
CONNECTIVITY_INTERNAL permission
Bug:21637535
Change-Id: I5991d39facaa6b690e969fe15dcbeec52e918321
During error recovery, if the mBluetooth pointer is reset to null,
reset the mBluetoothGatt pointer as well.
Bug: 21756298
Change-Id: I26204ba47dd3c5465bb7de30cfa5dc0f07eee2fd
Derive the correct current volume UUID for comparison, and only
check for cluster style installs when moving from internal storage.
Bug: 22616484
Change-Id: Idb6be2aa4aaa9b9f47ebbeeebd65c15a60d5d164
BUG: 22287469
1) Fix SyncManager waking up every 2 hrs if there is nothing
to do.
2) Fix sync wake-up alarm not being properly updated if the new
alarm was in the future.
2a) Due to staus bar sync signal that were removed post-K
one of the wake-ups was for 30s in the future, removed this
@hide intent completely.
3) The SyncManager will still set a timeout alarm for 5mins after
the start of a sync. Leaving this in as to post to a handler is
less expensive but more complex, and the alarm update is
correctly working now.
Change-Id: If51c9dd68391ccaeb480a17eb5a1364c4afe4c2a
