Do not return every rotation for window metrics.
Bug: 228288352
Test: atest WmTests:PossibleDisplayInfoMapperTests
Change-Id: I756b079bfce09cf618500f3d07547ec94ac60694
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
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
Currently there is a codepath in native DisplayEventDispatcher
introduced by aosp fc690e2a2d1d3cf08d71a02c4ecd14665c0f2039.
It accounts for vsync timeout. Here in java choreographer, we don't want
to divide by zero for logging messages so a check is added. There are no
real logic changes.
Test: atest ChoreographerTest
Bug: 229685140
Change-Id: I80f24abb89b9d961b017aca93340b1b02af6f66c
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
There are 2 cases that an insets source control doesn't have a leash:
1. The server hasn't applied the transaction of the initialization of a
leash yet.
2. The control is a fake control. It is dispatched when the insets
source is shown transiently by the server and we don't want the
client to change its layout.
We should only defer the insets animation for case 1. This CL uses
the insetsHint to tell if a control is fake or not.
Fix: 227083463
Test: atest --iterations 10 OpenAppNonResizeableTest
Change-Id: I45f75d8013f5723b782857101d070729cf082166
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
InputDevices can be reconfigured when pointer capture changes, but the
app will be notified via InputManager when the updated device
information is available. This races with the onPointerCaptureChange
callback, so advise the use of InputDeviceListener in the pointer
capture documentation for developers to get around this.
Bug: 226425883
Test: None
Change-Id: I7aeb23722dc40b8fd37cb9667a4f23a336e8b5f1
