Window relayouts (and subsequent binder calls) are common performance issues
and the reason for relayout can be hard to determine in Perfetto traces.
This adds reason for triggered window relayout to the trace
if View tracing is currently enabled.
Bug: 231121537
Test: Using perfetto, see https://screenshot.googleplex.com/AgsM2pfidDAav7j
Change-Id: Ib1d9b673517eb80b09c6bacedd34e26cb502877b
- setColorSpace only supports Display_p3 and sRGB
Bug: 229735367
Test: test picture rotation and check log
Change-Id: If2d6ab965be28d35a3adf330e7050e16e40f9620
Before, there were two paths for listening to pip params changes, either
via onTaskInfoChanged (only handle aspect ratio changes the same way for
all form factors) and PinnedTaskListener.
Now all PiP params changes are handled in onTaskInfoChanged and use
similar listeners to allow for different behavior for different form
factors.
Also adds a TvPipTaskOrganizer so that only relevant params are checked.
Bug: 218456378
Bug: 220042536
Bug: 228854691
Test: atest PinnedStackTests
Change-Id: I673ab69ee9253db782c41da96695b5a374345086
Do not return every rotation for window metrics.
Bug: 228288352
Test: atest WmTests:PossibleDisplayInfoMapperTests
Change-Id: I756b079bfce09cf618500f3d07547ec94ac60694
As noted in the linked bug, in certain scenarios IC established callback
is not always called. As a fix, we make sure we don't return early when
MSG_BIND callback is received from IME
Fix: 228105257
Bug: 217971553
Test: atest StylusHandwritingTest#testHandwritingEndToEnd
Change-Id: I780327003f7145c4f9b9df4dc5243227d7e67d92
If the device is a tablet, the navigation bar will be taskbar, and it
will draw fake rounded corners above itself when it's shown and
unstashed. When apps request to hide taskbar from such state, it will
cause an extra window insets change from server side.
Move the calculation of rounded corner inset to client side so that we
can make the window insets change come only once.
Bug: 229825307
Test: atest WindowInsetsControllerTests ActivityRecordTests
Change-Id: I081142facbe0fe676b89c8883fa690ba5ae13d79
The screenshot animation must know whether the screenshot contains HDR
layers so that it can correctly inform SurfaceFlinger whether its layer
can be dimmed.
This is due to the interplay of the following:
1. Devices are now able to configure DisplayManager to send
significantly lower SDR white points relative to display brightness
to SurfaceFlinger when HDR is simultaneously on-screen.
2. AIDL composer is required to support per-layer dimming, so that SDR
layers may be dimmed to preserve the relative luminance of HDR video
content.
3. Because the screenshot does not contain an HDR transfer function,
SurfaceFlinger will treat the layer as SDR, and attempt to dim it.
4. Screen rotations containing HDR layers must request SurfaceFlinger to
present the rotated screenshot at display brightness, to override
(3) above. Otherwise, HDR content captured in the screenshot will
suddenly dim during the rotation animation.
5. Also due to (3), DisplayManager no longer thinks that there is HDR
content on screen, so a prior patch treated layers that requested to
to be dimmed to be reported as HDR
(I1d1b0dcaf230300ca34b84ea407d0817feb2c664). Otherwise, the display
brightness will decrease during the animation and ramp back up
afterwards.
6. But because of (5), screenshots that only contained SDR layers were
incorrectly treated as HDR, which caused the display brightness to
ramp up during the animation.
This patch fixes (6) by allowing for the screenshot animation to learn
whether the screenshot contains HDR layers, and request dimming
capabilities accordingly.
Bug: 230068567
Test: screen rotation
Change-Id: I6bbb2433f976e368bfe2c04e084e110cfb551c15
To prevent extra blocking calls to ActivityManager,
rather than calling
ActivityManagerWrapper#invalidateHomeTaskSnapshot,
add a transit flag to have ActivityTaskManager
handle this as part of the goingAway call.
Bug: 229890190
Test: atest SystemUITests
Change-Id: Ica1b552a332d0c946d6008965c1a2881b646e365
2 reasons that may unexpectly calls hideMySoftInput from IME:
1) When requesting show IME on the activity, before receiving the
control from server side, the null control might received from the
relayoutWindow, if initially in consumer side didn't get the control
yet, we should not hide the IME immediately to broke the on-going
show request.
2) When ImeInsetsSourceConsumer#onWindowFocusGained, if we don't set
mIsRequestedVisibleAwaitingControl as true if it has requested IME
visible but not yet get control, it also could possble mistakenly
hide IME when ImeInsetsSourceConsumer#setControl.
As the result, we should prevent both case with
1) add returned value for InsetsSourceConsumer#setControl to see whether
the control has changed from the server, if the control didn't
change like receiving a duplicated null control callback,
then in ImeInsetsConsumer didn't have to do anything.
2) set mIsRequestedVisibleAwaitingControl as true when receiving
onWindowFocusGained and the host is waiting the control to make
IME visibility reliable.
Bug: 227142436
Bug: 204524304
Test: atest FlickerTests:LaunchAppShowImeAndDialogThemeAppTest
--rerun-until-failure 10
Change-Id: If4b09f5b52bc96cf3429aaa912961f3ac4e326f2
Only allows keep clear area changes to be reported every 100ms.
Helpful to keep IPC from app to WindowManager to SystemUI lower during
animations, when Views marked as preferKeepClear change position a lot.
Bug: 226583836
Test: atest KeepClearRectsTests
Change-Id: I9f6c86c5345218c9ee40f50a74d4357dd4e94dc7
Manually "revert" ag/17188552 due to jank caused by
getLatestVsyncEventData as new blocking binder call on the main thread.
Test: manual open and close app to/from home.
Test: perfetto trace
Test: atest ChoreographerTest
Bug: 229987086
Change-Id: Idcab776f3f249cc9fd609a6438e29a50a1edaaf2
Currently there is a codepath in native DisplayEventDispatcher
introduced by aosp fc690e2a2d1d3cf08d71a02c4ecd14665c0f2039.
It accounts for vsync timeout. Here in java choreographer, we don't want
to divide by zero for logging messages so a check is added. There are no
real logic changes.
Test: atest ChoreographerTest
Bug: 229685140
Change-Id: I80f24abb89b9d961b017aca93340b1b02af6f66c
This CL fixes a race condition for IMM#showSoftInput, which surfaces
when it's called during an IME hide animation.
IMM#showSoftInput ends up calling WIC#show asynchronously, but at that
time the running IME hide animation may have already been finished
successfully, and WIC#show may fail to cancel the hide animation
(then the cleanup IMM#notifyImeHidden hides the IME again disruptively).
I think a clean fix is to have IMM#showSoftInput call WIC#show
synchronously. However, this requires a significant refactoring.
As a short term fix, this CL adds a boolean field indicating whether or
not IMM#showSoftInput has been called. If it's called, we skip calling
IMM#notifyImeHidden.
Bug: 221483132
Bug: 225674038
Test: atest InputMethodStressTest
Test: atest CtsInputMethodTestCases
Test: atest WindowInsetsAnimationControllerTests
Change-Id: I36d570630085d0bc34097a2433208601dc9cb0fd
(cherry picked from commit 4c607982ed)
Merged-In: I36d570630085d0bc34097a2433208601dc9cb0fd
Currently, IMMS will be notified asynchronously when an IME hide
animation finishes, via message dispatching through IMS
(IMM#notifyImeHidden -> IMS#notifyImeHidden -> IMMS#hideMySoftInput).
This creates a race condition when IMM#showSoftInput or WIC#show is
called around the end of hide animation.
This CL fixes the race condition by synchronously and directly
calling IMMS#hideSoftInput from IMM#notifyImeHidden.
Note that there is still another race condition for IMM#showSoftInput
(not WIC#show) if it's called during an IME hide animation;
IMM#showSoftInput ended up calling WIC#show asynchronously, but at that
time the running IME hide animation may have already been finished
successfully and WIC#show may fail to cancel the hide animation
(then the cleanup IMM#notifyImeHidden hides the IME again disruptively).
I will fix the latter issue in a separate CL.
Bug: 221483132
Bug: 225674038
Test: atest InputMethodStressTest
Test: atest CtsInputMethodTestCases
Test: atest WindowInsetsAnimationControllerTests
Change-Id: I7c71dc5a1d6b61aa79d1666f0e257e6401e4adb2
(cherry picked from commit 9065310f81)
Merged-In: I7c71dc5a1d6b61aa79d1666f0e257e6401e4adb2
Notably eliminate references in RangeInfo and CollectionInfo class
descriptions. We've just deprecated obtain and recycle, so keeping
outdated docs is confusing.
Test: builds
Bug: 229991765
Change-Id: Ia2d7963bf572740052e0da03950398d016a3caa4
Test cases:
- DO
- Verify disabled for entire device
- Verify still disabled after restart
- Verify no longer disabled when DO is removed
- COPE
- parent
- Verify disabled for entire device
- Verify still disabled after restart
- Verify no longer disabled when COPE PO is removed
- not-parent
- Verify disabled for user
- Verify disabled after restart
- Verify disabled when PO is removed
Bug: 217558483
Test: DevicePolicyManagerTest
OrgOwnedProfileOwnerTest#testScreenCaptureDisabled
ScreenCaptureDisabledTest
Change-Id: I977eb18619da46e1cfc5d0a8d351ea80d3ea7205
