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
This allows properly checking/noting against the voice interactor or
HotwordDetectionService as needed. Otherwise,
SoundTriggerMiddlewarePermission notes ops for data delivery to the
interactor, even if the data only reaches the HotwordDetectionService.
This is accomplished with a decorator for permission checks, that wraps
the real implementation. A proxy that serves as the remote Binder object
is also needed, to allow this decoration pattern.
The list of sessions stored in VIMS is removed for simplicity. It
currently serves no purpose (used only in dump() but doesn't implement
it so it's a no-op there).
DataDelivery checks will be addressed in a followup change.
Bug: 186164881
Test: manual - permissions are checked appropriately
Test: atest CtsVoiceInteractionTestCases
Change-Id: I80dabaf6ae0e781028dde16ead3321fbff319542
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
onTaskVanished may be called when an activity is moved to
the back while a resize animation is still in progress.
This causes a race between the windowing mode change to
fullscreen and the PIP resize that results in the
fullscreen task leash getting a PIP-sized crop.
This change cancels any ongoing animations in
onTaskVanished and makes sure that finishResize() is not
called when the animation is canceled because the transition
to fullscreen will handle the final resize and cropping.
Bug: 188856244
Test: enter YT PIP, click the next button and the music
button quickly after that, then re-open YT from the
notification - verify the activity is fullscreen and is
cropped correctly.
Change-Id: Ide52b8c6b63205081bde96472a5e0589664e1c8a
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
