- setColorSpace only supports Display_p3 and sRGB
Bug: 229735367
Test: test picture rotation and check log
Change-Id: If2d6ab965be28d35a3adf330e7050e16e40f9620
Do not return every rotation for window metrics.
Bug: 228288352
Test: atest WmTests:PossibleDisplayInfoMapperTests
Change-Id: I756b079bfce09cf618500f3d07547ec94ac60694
In the initial implementation, HandwritingInitiator looks for a
handwriting candidate view when a stylus motion has exceeded the touch
slop distance.
This updates the implementation to look for the handwriting candidate
view in the stylus down event. The overall resulting behaviour is
unchanged.
This is needed for an upcoming change to stop dispatching MotionEvents
to the view tree if they are for a stylus movement on a handwriting
candidate view, in order to prevent scrolling before handwriting is
initiated.
Bug: 228210945
Test: atest CtsInputMethodTestCases:android.view.inputmethod.cts.StylusHandwritingTest
Change-Id: I395c2ec4b16a3fd3cb56308da872ec959e93943e
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
Introduced View#setHandwritingBoundsOffset and xml attributes to
enlarge the view's stylus handwriting bounds. With this API, it's
possible to make handwriting bounds larger than the view's visible
bounds, and makes handwriting easier to trigger.
Bug: 211764956
Test: atest android.view.stylus.HandwritingInitiatorTest
Test: atest android.view.cts.HandwritingBoundsOffsetTest
Change-Id: I7a3749f78df82eee08ad29761cd52d7452114873
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
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
This enables handwriting to be started before the input connection is created for custom text editor views which are not EditTexts.
Fix: 218907674
Test: atest CtsInputMethodTestCases:android.view.inputmethod.cts.StylusHandwritingTest
Change-Id: I1ff3b0ffd609e1ec9f1efc477d00fee998ac9966
