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
In current desgin, the confgis for cutout and rounded corner are based
on the original display size. If the display resolution is overridden,
cutous and rounded corners will be drawn in incorrect places with
incorrect size.
We should load the cutout & rounded corners with the orignal display
size and then scale the results with the display ratio which is
calculated by dividing current size with original size.
Bug: 209592558
Test: manual:
1. Go Settings-> Display-> Screen Resolution
2. Switch between FHD+ and QHD+
3. Check if the cutout and rounded corner looks the same as they
are in the original display size.
Test: manual:
1. adb shell wm size 1080x2340
2. Check if the cutout and rounded corner looks the same as they
are in the original display size.
Test: atest DisplayCutoutTest LocalDisplayAdapterTest
ScreenDecorationsTest RoundedCornerResDelegateTest
Change-Id: Iea42b73c0276b82983c1ddbce9455355afdc164d
Some TextViews are made as password via input type but does not
contain autofill password hint. This change auto append a hint
for autofill to identify.
Bug: 219844915
Test: atest android.autofillservice.cts.dialog.LoginActivityTest
Change-Id: Ifd18c56ffe788a601821d178ace41413f9e0454e
For the performance consideration, we don't prefer to trigger a
FillRequest for autofill dialog at the Activity starting. We only do
that if one of the fields is a password or contains the allowed
AutofillHints for fill dialog.
Bug: 219844915
Test: set device config, check whether do a fill request at starting
Change-Id: I8cc8c99d1f0e716ad293fa612f65aa2a8d23b028
The window matrix of the embedded window is not updated if the second
host SurfaceView doesn't have any offset. To esnure the window matrix
is up-to-date, we force to update the matrix when the embedded hierarchy
is initialized.
Bug: 229178859
Test: atest InlineFilteringTest#testFiltering_filtersByPrefix
atest android.accessibilityservice.cts
Change-Id: Ib23af520fcbaa1788e3ef22a1086b90a0801375c
Our initial attempt to allow updating the configuration of
SurfaceControlViewHost was insufficient when the SurfaceControlViewHost
is using a service context. This service context will always be
on the global configuration, and ViewRoot won't be able to override it.
We add some documentation suggesting the user use a window context,
and wire up SurfaceControlViewHost VRI so that they are the authority
on configuration (and propagate the change in to the context).
Bug: 215204813
Test: SurfaceControlViewHostTests. Manual in game overlay+split-screen
Change-Id: I24c0309593b7fddaeab8db355f63a5f6bd763562
This is a follow up CL to our previuos CL [1], which enabled
AccessibilityService to use a subset of InputConnection APIs.
In that CL we have reused existing AIDL interfaces that were designed
and maintained for IMEs for simplicity, where a non trivial amount of
unnecessary IPC endpoints were included.
From the security and maintainability viewpoints, however, exposing
unnecessary IPC endpoints is discouraged in general. To address such
concerns this CL introduces a set of dedicated IPC definitions for
A11yIME so that we do not need to reuse IPCs for IMEs.
This CL also stops passing InputBinding object to A11yIME process as
it contains IInputContext Binder Proxy, which can still be used to
directly invoke fallback InputConnection. This is doable now because
A11yIME no longer relies on fallback InputConnection [2].
This CL is should not have any observable changes in the semantics.
End-to-end CTS tests guarantee that everything is still working as
intended now and in the future.
[1]: Ia651a811093a939d00c081be1961e24ed3ad0356
fb17e5ae7a
[2]: I2af3cd50444d8ddf25aa0f6479238156914e6fff
dc635efb68
Fix: 215633021
Fix: 215636776
Test: atest CtsInputMethodTestCases:AccessibilityInputMethodTest
Test: atest CtsAccessibilityServiceTestCases:AccessibilityInputConnectionTest
Test: atest CtsAccessibilityServiceTestCases:AccessibilityImeTest
Change-Id: I5ff2e804cbcf90828370a0612ff54111130bdff4
If we destroy and recreate a SurfaceView in the same frame its
possible for positionChanged for the new surface to arrive
before positionLost for the old surface. In this case we
won't clear mRtLastReportedPosition, and so we won't set
any position at all on the new surface.
Bug: 229052731
Test: Existing tests pass
Change-Id: I896496afa5b05848f96b20697d33911cae9639a7
VRI can initiate syncs, but they can also happen from other places when
using SurfaceSyncer. When VRI initiates the sync, sometimes the buffer
needs to be synced. Other times, we just want to know the buffer has
drawn, but don't actually need to sync the buffer.
When a sync is initiated from outside VRI, using SurfaceSyncer, we
always want to sync the buffer. This change ensures that if the sync was
started from an outside request, it will set mSyncBuffer to true.
An additional part to clarify the sync logic, renamed mLastSyncId to
mSyncId and renamed isInSync to isInLocalSync to clarify that the
mSyncId only represents VRI initiated syncs.
Test: Internet Dialog syncs buffer
Fixes: 229098223
Change-Id: I99e9e6341a487d59c33a33a61e442be7909518c2
Before the new insets system, a window wouldn't receive visible insets
if it:
- has FLAG_LAYOUT_NO_LIMITS,
- is not TYPE_WALLPAPER or TYPE_SYSTEM_ERROR, and
- is not in multi-window mode.
This CL makes the visible insets compatible with the legacy insets
system.
Fix: 223536648
Test: atest InsetsStateTest
Change-Id: Ia73142cfae701d0532a9a397366c50aeef82abb2
The attachInfo from ViewRootImpl is not reliable
for DisplayArea manipulation or windowless window.
To fix this problem, we use the transform matrix of
InputWindowHandle, which could transform the bounds
from window coorindate to screen coordinate. We also
transfrom the bounds to logical display coordinates
with the associated display matrix.
Besides, we also record the magnification spec of the window,
which could get the bounds before magnification. We use
this value to decide the property 'visibleToUser'.
Bug: 200797785
Test: atest android.accessibilityservice.cts WindowInfoTest
atest com.android.server.accessibility
Change-Id: I0917b04fe8b027fb2bd932a6f0604ba1449ebc66
WindowInsets#getStableInsets should return system bar insets as if
system bars are visible, regardless of the window flags.
Fix: 228807465
Test: See if a window with FLAG_LAYOUT_NO_LIMITS or FLAG_FULLSCREEN can
receive all the system bar insets.
Change-Id: Ib8fff5ba78c8f52141a048027821ef182d2f7992
The getSfInstance usage on ViewRootImpl is target to reduce jank
when moving split divider, but legacy split is going to be depracated
and it didn't used on new split too so we can remove whole related
codes safely.
Bug: 222696368
Test: build pass
Change-Id: Icf9b543bdd1d4bee54efb3be852722f247d1bd47
Main motivation is to store a back callback's exact priority value in WM. This is required by the IME migration (ag/17076160) to compare the priority levels of IME window callback and focused window callback in BackNavigationController.
This also consolidates the WindowState#mSystemOnBackInvokedCallback and WindowState#mApplicationOnBackInvokedCallback fields into one field, as tracking two fields for one callback was error prone. We had to remember to clear the application / system field when the other field is set, and failing to do so has resulted in bugs such as b/222675481.
Bug: 224856664
Test: atest BackNavigationControllerTest
Test: atest WindowOnBackInvokedDispatcherTest
Test: m -j and test back behavior throughout the system on apps that
opted in and out.
Change-Id: Ic57113610d934f33d2c9ca4cef59f39a9b87e832
* changes:
[automerge] DO NOT MERGE: SurfaceControlViewHost: Restrict disclosure of input token 2p: 0cfda55b95
DO NOT MERGE: SurfaceControlViewHost: Restrict disclosure of input token
The very first state of touch mode is obtained from addToDisplay. It
should be applied in the first performTraversal regardless of mStopped.
In this way, when an app window is re-created at the background, the
touch mode state can still be up-to-date.
Fix: 227843343
Test: 1. Open Chrome and go to the homepage.
2. Change the theme via the 3-dot menu > Settings > Theme.
3. Go back to the homepage and see if any button is focused.
Expected behavior: no button looks focused.
Change-Id: I2681e2436dd265abe9cd9bdd56ee5799fa30d89b
This change will change the providedInternalInsets from a single insets
to a insets array. The one adding the insets can make use of the array
to apply different insets to the window when calculating the provided
insets by the window for different insets types.
With that, the task bar can provide zero insets for the tappable element
type when stashed.
Bug: 215411414
Test: DisplayPolicyTests
Change-Id: I84cd7ef6a2bc19229d3c09f752f65c83eb5c7dde
Currently we send the input (channel) token from the embedded
view hierarchy to the remote embedding process via SurfacePackage.
This is used to call grantEmbeddedWindowFocus. However this could also
allow the host process to invoke updateInputChannel, which is not
desirable. To fix this we rework updateInputChannel to work in terms
of a focusGrantToken, which only carries this 1 capability.
SurfacePackage is modified to not include the input token, but rather
include this focus grant token.
Bug: 215912712
Test: SurfaceControlViewHostTests
Change-Id: Ie278f678f12f50c32f142a4260ff7d1c2a9ca57c
(cherry picked from commit 501ee91b95)
