Views may be re-used (e.g., as in ListView and RecyclerView) so we need
to ensure they don't have the translated text when they appear again.
RecyclerView seems to recycle translated views even when
`hasTransientState() == true` which is the case when views are
translated. This should be fixed separately.
Bug: 223700458
Test: atest CtsTranslationTestCases
Test: atest CtsContentCaptureServiceTestCases
Test: atest CtsAutoFillServiceTestCases
Test: manual - New messages are translated correctly even if views are
re-used. Messages are translated correctly when scrolled onto the screen
and stay translated while on-screen.
Change-Id: I97cc418a801c006c857e971110ab811ad383343e
mSurfaceLock is used to ensure the Surface object stays valid over
the span of the calls to lockCanvas and unlockCanvasAndPost which could
come from any thread. In API Level 29 and below, updateSurface was
split in to two paths, a first path (which would acquire mSurfaceLock)
for when the Surface could be destroyed, and second path for geometry
updates only. The consolidation of these two paths in updateSurface
created an overlocking of mSurfaceLock, which is now acquired even
when mSurface won't be modified. In fact it's acquired whenever the
geometry changes. This means an application rendering thread which
creates delays between lock and unlock canvas could create undesirable
and needless delays on the main UI thread, if the SurfaceView geometry
updates. We also have some underlocking, where we aren't actually
locking when destroying the SurfaceView.
Test: Manual with test app
Bug: 206846658
Change-Id: Idc17d111eee7a7365af4e94a156e7c46c7ea8171
Apps have only one chance to get Autofill dialog support, it requires
attaching the autofillable view before the Activity has finished
laying out. This change moves the doing request to the view being
laid out, that is the same timing with what Autofill is doing about
the view is auto focused but under different conditions.
Bug: 226674898
Test: atest android.autofillservice.cts.dialog.LoginActivityTest
Change-Id: I9018b8db8673e3b917a303476666ae766fbe7891
Merged-In: I9018b8db8673e3b917a303476666ae766fbe7891
The PositionUpdateListener sometimes gets called after the
FrameDrawingCallback, because there is no ordering guarantee between
these two callbacks. This causes the BlurRegions sent to SF to
not have up-to-date positions. For example, an empty Rect gets sent
as the blur region bounds, because the position update hasn't arrived
when the surface transaction is sent. When the position update arrives
it set the correct bounds, but it requires another draw to happen so
that the correct position is picked up.
This CL fixes this issue by saving the blur regions that were last sent
to SF in FrameDrawingCallback and sending another transaction when the
position update arrives. That transaction is merged into the previous
one for the same frame, so the final transaction sent to SF has correct
values.
The CL also moves the FrameDrawingCallback registering logic entirely in
the BlurAggregator in the first onPreDraw. This cleans up VRI
Bug: 197239228
Test: atest --iterations 100 BlurTest#testBackgroundblurSimple
Test: atest BlurAggregatorTest
Change-Id: Ia122df40fdf2aa124299461c2e2597b61fa92699
We currently close the IME by having the target application forward KEYCODE_BACK to the IME process through InputMethodManager#dispatchInputEvent and having the IME handle the keycode in InputMethodService#onKeyDown. When apps opt in to OnBackInvokedDispatcher API, we will not dispatch KEYCODE_BACK to apps anymore. Thus we need to migrate IME to the new API for it to close on back invocation.
This implementation forwards OnBackInvokedCallbacks from the IME process
to the app process. This is necessary because all callbacks need to
exist in the app process for them to be considered by hardware back keys. While back gestures go through WM to resolve callbacks from the focused window, hw keys are directly sent to the focused window's ViewRootImpl, bypassing server side back nav logic.
Bug: 228358882
Test: atest CtsInputMethodTestCases:KeyboardVisibilityControlTest
Test: atest CtsInputMethodTestCases:InputMethodServiceTest
Test: atest CtsInputMethodTestCases
Change-Id: Ie207b63b11a56c9b2173f26b734a27b13ebccc60
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
Adding documentation to clarify when should the applications use LayoutParams.preferredRefreshRate
over LayoutParams.preferredDisplayModeId
Bug: 227781356
Test: built locally
Change-Id: I75f10f7ea2c3386f8382af3012241316e540bd83
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
Nulls out `info.mPositionUpdateListener` after unregistering the
Listener, allowing a new PositionUpdateListener to be registered later.
`addPositionUpdateListener` was only called if
`info.mPositionUpdateListener` is non-null.
The Listener is first created and registered if the system needs to keep
track of the View's bounds (eg. if it is marked as a keep clear area).
If the system no longer needs to keep track of the View's bounds, the
Listener is unregistered, but wasn't set to `null`.
When the system later needs to receive updates about the View's bounds
again, the listener failed to be re-registered because it was non-null.
Bug: 226583836
Test: Manual, check position updates of View
Change-Id: Ia494e84843a9954e368d76a000f5f725e3a58df1
