Used in PackageManagerOTATests to verify upgraded system apps
are granetd new permissions.
Bug 11271490
Change-Id: Idbc07bc043d06ea15dc41285ecbfb8186a7ecc95
The possibility existed that an activity was set to a task that it was
already being set to. If that were to happen, and it was the only
activity in the only task of the stack the stack would be deleted.
This fixes that situation and logs it as well to confirm that it does
fix bug 11272935. Logging to be deleted upon successful monkey run
exhibiting the log.
Change-Id: I436fdcc9a3734adad81d3ef90f29b93b3ac4dfcd
Setting the same code is redundant, and may cause supplicant to drop
currently connected connection.
Bug: 11303252
Change-Id: I1af57b3af2d0b8cc51939a8b9872fb3fe0105a91
The existing code wasn't retaining the requested window bounds, if any,
and so could wind up rebatching alarms into much longer potential
delivery windows than originally demanded by the caller. This could
wind up delivering alarms outside their designated windows entirely.
Bug 11324357
Change-Id: I4d418cd08702e397b3c7692b412d4bf51d5d9e4b
This fix ensures that only one runnable is running at a time, no matter how
many events come in. There's probably a better way to do this, but this is a
safe fix.
Fixes bug 11307391
Change-Id: I007c95062b20285571f39603c95fb9174b9a2da3
When a translucent window is closing, the transition
animation to Launcher is janky because Launcher is
expected to be 'opening' but it has always been open
underneath the translucent window. Therefore, the
animation applied to the translucent app appears
janky.
bug:11253262
Change-Id: I9b6af3291d119e6927401f63785b12f25573f4eb
This works around a problem where removing a review with unfinished
transitions results in leaked object references to KeyguardTransportControlView.
The workaround disables transitions until we have a better fix.
Fixes bug 11307391
Change-Id: I1df82f2c6f1cd9f5c9076d4c76cfd4aec3b6806c
The APIs are createBond, setPin, setPairingConfirmation
The intent is ACTION_PAIRING_REQUEST
bug 11101076
Change-Id: I3a314efd973b3ce078ab5347159c336f222d9f15
Also disables all setting of PAC networks through the internal AsyncChannel
methods. PAC can only be saved through addOrUpdateNetwork for permission
checks.
Bug: 11316946
Change-Id: I51016b578080c342a5e5d536ea9a3fdd4fe16644
Fix CountryDetector NPE by calling CallerInfo.getCurrentCountryIso() which
checks for potential nulls.
Bug:11291034
Change-Id: I0a4412c432551c64ec30652d69636442653ee337
In this case:
1. Privileged system app FOO is overlain by an installed update,
2. FOO was replaced during an OTA,
3. The new in-system FOO introduced new privileged permission requests
that had not been requested by the original FOO,
4. the update version of FOO still had a higher version code than
the new FOO on the system disk, and
5. the update version of FOO had been requesting these same (newly-
added-to-system-apk) permissions all along;
then the newly-added privileged permission requests were incorrectly being
refused. FOO should be able to use any privileged permission used by the
APK sited on the system disk; but instead, it was only being granted the
permissions used by the *original* version of FOO, even though the system
FOO now attempted to use them.
Still with me?
The fix is to (a) properly track privileged-install state when processing
known-to-be-hidden system packages, and (b) to tie the semantics of the
permission grant more explicitly to that evaluated state, rather than
using the prior (rather fragile) fixed-up privilege calculation applied
to the overlain apk's parse records.
Bug 11271490
Change-Id: Id8a45d667e52f3b5d18109e3620d5865f85bb9c9
