RoleService should not be calling onRoleHoldersChanged() on
pre-created users, but that behavior cannot be changed because its
implemented by a system app, and pre-created users APIs are hidden.
To test it:
$ adb shell pm create-user --pre-create-only --guest
Success: created user id 12
$ adb shell pm create-user --guest ElGuesto
Success: created user id 12
$ adb shell cmd user list --all -v
4 users:
0: id=0, name=Driver, type=system.HEADLESS, flags=ADMIN|INITIALIZED|PRIMARY|SYSTEM (running)
1: id=10, name=Driver, type=full.SECONDARY, flags=ADMIN|FULL|INITIALIZED (running) (current)
2: id=11, name=null, type=full.SECONDARY, flags=FULL|INITIALIZED (pre-created)
3: id=12, name=ElGuesto, type=full.GUEST, flags=EPHEMERAL|FULL|GUEST|INITIALIZED (converted)
$ adb shell am switch-user 12
$ adb shell dumpsys voiceinteraction |egrep '(mBound|implementation)'
mBound=true mService=android.service.voice.IVoiceInteractionService$Stub$Proxy@77da1bc
$ adb shell cmd voiceinteraction show
Test: see bove
Bug: 216141085
Bug: 226201975
Change-Id: I12d9bb32e144ecf91ee4b452affea0dcea546127
The client computes the window frame on its own in ViewRootImpl#setView.
However, the bounds obtained from WindowConfiguration is not size-
compatible, which makes legacy apps produce wrong frames. The frame is
larger than expected, so when computing WindowInsets with size-
compatible InsetsState, the window cannot receive insets.
Although the client will receive the correct window frame from relayout,
but the first WindowInsets has been dispatched before that.
This CL sends the size-compat scale to the client, so the client can use
the correct WindowConfiguration to compute frames.
This is also a step to enable the client to perform local window layout.
Bug: 237749017
Bug: 161810301
Bug: 175861127
Test: atest StartingSurfaceDrawerTests WindowAddRemovePerfTest
ActivityRecordTests WindowManagerServiceTests
Change-Id: I6b23901f4b1f009444c04da7e078ea971a386ad7
To audit data access and verify the uid and package are consistent,
use noteOpNoThrow instead of checkOpNoThrow.
Bug: 187439908
Test: atest AssistDataRequesterTest
Test: atest CtsVoiceInteractionTestCases
Test: atest CtsAssistTestCases
Change-Id: Ib48040b5b55be09958da4398f4d663908573568c
Java side for a new API, setFrameRateDefault, where policy implementation logic is made using setFrameRateDefault instead of checking window types.
Bug b/192291754
Test: manual
Change-Id: I3ff35dbe3551746b90448531dccec09d8355824c
Since Android API 31 there is a new check in StrictMode, this
check ensures that any ui-related operations involving context
object are only performed on the ui context. If the context is
not the ui context, it will fail with error when calling the
ui-related methods.
So we need to create proper ui context if original context is
not a ui context.
Bug: 220698651
Test: atest CtsVoiceInteractionTestCases
Test: manual. Test VoiceInteractionSession UI.
Change-Id: Ibbeae9b135b90078b3b9e36a2d0c5a92f6184b2a
This reverts commit:
db407ef12d, and
d8aa7f7882.
Reason for revert:
The surface size would be reduced by mTranslator unexpectedly.
Fix: 233017734
Test: Open a legacy app which has CompatibilityInfo.SCALING_REQUIRED
and see if the app is cropped.
Change-Id: If830866328a5709cf6856fe840a804b304052003
The attached frame is the frame of the parent window that its child
attaches to, as long as the child is not
TYPE_APPLICATION_ATTACHED_DIALOG. It is a factor while computing the
window frame.
Previously, we let the child obtain the attached frame from its parent
view root. However, if the parent and the child are not in the same
process, it can be tricky.
This CL sends the attached frame from the server to the client via
ClientWindowFrames. In this way, the child can compute its window frame
without having to accessing the parent view root.
Bug: 161810301
Bug: 175861127
Test: atest ActivityRecordTests WindowLayoutTests
Change-Id: Ia844a4c927027e305a56114216eaee2bf7933b1f
cleanup.
This ensures the memory is properly cleaned up if an exception is thrown
while building the DreamMetadata object.
Bug: 234343900
Test: locally on device
Change-Id: I29b2bed30c216d5e353fa0a8b0da74579b33cecb
The force-relayout was added in [1] for the side effect of [2].
Since the preserve-surface has been completely removed in [3].
So [1] can be restored to avoid unnecessary cost.
WallpaperService always calls relayout with View.VISIBLE, so
unless it requests to remove the wallpaper window, its surface
should not be removed. Though currently there might be no such
cases, add a log in case something goes wrong.
[1]: I79f97df61696eea325183e9b9057cbb10ce8cc66
[2]: Iea8ed86a9c4a7674804152aa44df7ef3d6341768
[3]: I4574ac0d3b8a63b13ac44846e729b73ca0f88f23
Bug: 233599092
Test: No additional relayout from wallpaper when turning on screen,
swiping/closing up to home.
Test: Toggle overview from wallpaper picker while using live wallpaper.
The wallpaper won't disappear.
Change-Id: I6673e458b5577f780be17a51cf5de1d6493ab5ca
Because animators are not tied to the lifecycle of any UI
elements, it is possible for an app to go into the background
and for the animators to continue running. Ideally, the app would
track the lifecycle of the activity/etc and pause or disable the
animators, but it is common for this to not happen, causing the
animators to continue spinning when the app does not need them.
The animators are not causing as much work as for a foreground
activity (since they do not cause any re-rendering), but they cause
work nonetheless by keeping Choreographer awake to continue pulsing
frames.
The ideal fix would be to introduce new API for animators that
tied them to lifecycle concepts (View, Activity, etc). But that kind
of fix would only be available for future versions of the platform,
and does not address existing app code. A workaround for the current
situation is to address the most egregious problems; infinite animators
running on backgrounded apps.
The fix here is exactly that: when an app's visible surface (either an
activity or, for Wallpapers, a WallpaperService) is backgrounded,
a request is sent to pause animators for that surface. When that surface
comes to the foreground, a request is sent to resume those animators.
Since all animators are handled on the same thread for the same process,
in AnimationHandler, we should only ever pause animators when *all*
surfaces for a process are not visible (and resume them when *any*
surface becomes visible). Also, to mitigate any issues with thrashing
animator state for apps which become only transiently backgrounded,
we delay pausing for some time.
Bug: 228598053
Bug: 233391022
Test: new AnimatorLeak CTS test, plus manual testing for activities
and wallpapers
Change-Id: I8b9f841cc80babb972244c724968a5c085a06b69
Merged-In: I8b9f841cc80babb972244c724968a5c085a06b69
