Introduce an API for app to query if currently selected InputMethod
supports stylus handwriting
Test: atest StylusHandwritingTest
Bug: 228514000
Change-Id: I0c606e94780ae6636585ab36b751fbf6e90a1cbf
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
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
This change adds two WM transit types for opening and closing dream
activities, which allows the system to define transition in and out of
dreams, that are currently being overriden by other transitions.
Set the priority to be just below keyguard transit. The keyguard
occlude/unocclude already correctly handles the dream open/close
animation.
Bug: 222507937
Bug: 220311554
Test: atest WmTests:AppTransitionControllerTest
Test: manually on device by entering and exiting dreams over keyguard,
launcher, and settings. observed animation and relevant types of WM logs.
Change-Id: Iedfa279d56cd9d4c4679cb3b697ee74a98ef727b
The methods are only used in system server. It is unnecessary to
declare in aidl.
This also eliminates the confusion of missing permission check
for updateRotation().
Bug: 230863943
Test: atest WindowManagerPermissionTests
Change-Id: I703830650bab3a792982cada99aa1512430658a4
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
