Otherwise if keyguard changes to be showing when booting
and keyguard secured state has not been updated yet, it
will cause allowSnapshotHome to be true. And then take
snapshot for FallbackHome, that is useless and wasteful.
Bug: 192400758
Test: "adb shell dumpsys window w | grep -A5 SnapshotCache"
should show zero entry after device is booted.
Change-Id: Ia4afe69a70065fc3972fb9cb3dccc1e4b3b35a79
ag/13692058 added "com.android.shell" into resolveUid(), which is also
used by appops shell command. However unlike the other special UID
names (e.g. root, shell, media, audioserver), "com.android.shell" is a
regular package name, so this broke the assumption that the UIDs
returned from resolveUid() are all special UIDs that only runs in the
primary user, and made the shell command always set the package mode
for the com.android.shell package in primary user despite being given
an explicit --user parameter (see parserUserPackageOp()
implementation).
So the fix should be keeping the resolveUid()'s semantics and make it
only handle the special UID names instead of package names. For the
special case for shell in verifyAndGetBypass(), it can be done in that
method locally.
Bug: 187329570
Test: adb shell appops set --user 10 com.android.shell
MANAGE_IPSEC_TUNNELS allow
Test: adb shell dumpsys appops | grep -5 shell
Change-Id: Ia3157d6fd45dad085fa672e385287817fa20e90b
After Ic78c603b2375d36cf2170b81cca7cddbf334408b, sometimes there will
call keyguardGoingAway twice to trigger the second phase unlock
animation, so several conditions the remote animation may not execute,
so better to send the callback to update the status in window manager.
Right now the framework cannot ignore the second keyguardGoingAway call
because keyguard status in KeyguardViewMediator could be hiding, so
better to trigger startKeyguardExitAnimation once there was receive
keyguardGoingAway.
Still need to find out why will keyguardGoingAway been called twice,
better to merge those call together.
Bug: 190040281
Test: No hanging when launch app and received two keyguardGoingAway
calls.
Change-Id: I3c425066e2fc2d00dc8f55f470efa229607ac83f
Specifically, mentioning that the alarm count can only be included with
the alarm if the supplied pending intent is mutable.
Test: make offline-sdk-docs
Fixes: 178413211
Change-Id: I2914bceebeed8b52b0de11d70960aa33e6837b13
Also re-create the QAW client if the wallet feature is unavailable; and query the wallet cards only when the wallet feature is available.
Test: atest
Test: manual
Bug: 190036483
Change-Id: Ibad3429a6f77d3f8a474b577759e7b7193ad6f23
Shell doesn't need this permission and it confusing to the user
if visible in Settings.
Test: Shell doesn't appear in Settings under
Settings -> Apps -> Special app access -> Alarms & Reminders ->
3 dot menu -> Show system
Bug: 190775895
Change-Id: I98b051f37f3edf4f616f8847f691b956dafbdd12
Merged-In: I98b051f37f3edf4f616f8847f691b956dafbdd12
They can already use a lot of APIs to perform work in the background
and it simplifies the logic handling permission state changes and the
return value of canScheduleExactAlarms.
The major changes in behavior are:
1. Allowlisted apps can schedule unlimited alarm-clock alarms. This
should be the same as pre-S behavior.
2. If they happen to get the permission revoked, due to whatever reason:
user revocation, deny list, or app update, their alarm-clock alarms will
stay safe like their other exact alarms.
3. The API canScheduleExactAlarms is now true to its name: It returns
true even if the app is allowlisted.
Test: atest CtsAlarmManagerTestCases:ExactAlarmsTest
atest FrameworksMockingServicesTests:AlarmManagerServiceTest
BYPASS_INCLUSIVE_LANGUAGE_REASON=Existing APIs
Bug: 191716678
Bug: 190625528
Change-Id: I420694455f50aac10cf49cd43ff3b98575d86e9f
No matter the app is not found or has different uid, return
the invalid id to indicate that the add operation is failed.
So the caller won't know whether the specified package exists
or not.
Bug: 189122913
Test: Pass intent with specified component name to
ActivityManager#addAppTask.
Change-Id: I013264414c60f2d9864a5fcc369180425f20529e
- Remove the restriction of no animation to adopt fixed rotation.
Because the old case no longer happens.
- Always use orientation of keyguard if its window is visible and
device is going to sleep or is sleeping. This avoid unexpected
orientation change such as entering portrait AOD while the display
is landscape due to the requested orientation of top app.
- If device is fully awake, do not use the orientation of keyguard
if it is going away or is not showing. So if keyguard cancels the
showing state, its orientation won't affect the top app.
- Remove unused states and methods in WMS.
Bug: 191446147
Test: atest DisplayContentTests#testOrientationDefinedByKeyguard
Test: With remote keyguard swipe animation enabled.
Launch a landscape app and lock device.
Unlock by swipe. The landscape app should show in
its original orientation directly.
Change-Id: I77708fa9e28cf61c9dfd7aef8da77c3169ce5ad9
Set the default value of the list subscribe to false because there are not many carriers support the list subscription
Bug: 190683278
Test: atest RcsUceAdapterTest
Change-Id: I146637fda050a74f593c1b221364c18a03d2da5e
