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
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
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
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
In general this removes commit b2e3780. Because since rotation
is a part of configuration, it is enough to redraw according to
the configuration change.
Otherwise because forceRelayout is also used for syncRedraw,
that will cause to drop pre-allocated buffers and increase the
time of the initial frames for reallocation.
Bug: 229366100
Test: ActivityRecordTests#testLandscapeSeascapeRotationByApp
Test: Rotate 180 degree with various apps and no upside down
afterimage remains on the screen.
Change-Id: I3f03f7c8674ddc4a8c0b9c0b0528816114075732
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
