On larger screens, having the light z value lower down creates an
undesirable amount of shadow since the source to view angle can be quite
large. By scaling the z position of the source relative to the screen
size, we can avoid these extreme shadows.
Bug: 227425789
Test: run cts -t android.uirendering.cts.testclasses.ShadowTests --module CtsUiRenderingTestCases
Change-Id: I8b7a3fcf93daaa565256a08f38deffed74b24ad4
It's possible for close to be called during local cleanup concurrently
with the remote call.
A recent change (ag/15993920) added a missing Binder.unlinkToDeath
call to close(). This now causes a crash now if the registration
was removed at just the right time in another thread. This synchronizes
access to close() to avoid this.
Bug: 237406501
Test: atest ScrollCaptureConnectionTest
Change-Id: I0126bfac1efdece2e4eff144a44f29a963553b74
Follows the same exact pattern as the window attach and window focus
listeners in the same class.
Bug: 235403546
Test: Verified as part of follow-up systemui CLs
Change-Id: I7c825baf5913e6e0b85f475503639a4d17483d4e
When adding a window to WMS, its z-order may be higher than IME
initially. And then, WMS will move IME to the top of the new window.
Although IME is invisible during launching an app, that causes a change
in WindowState#mAboveInsetsState. And it would trigger a redundant
onApplyWindowInsets at the client side.
This CL treats null IME source as invisible IME source in
InsetsState#equals when excludeInvisibleImeFrames is true.
Bug: 237749017
Test: Add logs in dispatchApplyWindowInsets, and see if it gets printed
twice while launching an app.
Change-Id: I5eba7732619f7ceebe3152e81037a43e9ab3d91f
When a child SurfacePackage is set on a SurfaceView, the view's
RemoteAccessibilityController calls linkToDeath on the SurfacePackage's
IAccessibilityEmbeddedConnection. The death recipient -- the controller
itself -- is unlinked when the Surface is destroyed -- being notified
through a SurfaceChangedCallback registered on the ViewRootImpl.
There are 2 issues there:
* When the SurfaceView is detached, the SurfaceChangedCallback is
unregistered, so the unlinkToDeath never happens.
* The Surface holding the SurfaceView may never be destroyed, for
example in the case of the IME.
SurfacePackages sent over ipc seem to be used in only 2 places
currently:
* For inlined autofill suggestions in the input method. This bug causes
a serious leak here, since the memory is held in 2 persistent
processes -- autofill Session data in the system server (referenced
from the SurfaceViews), and SurfaceViews in the IME.
* The Wallpaper app.
For now, this is fixed by using a WeakRef for the
RemoteAccessibilityController. The root cause will be fixed in a
followup change in a later release.
Fix: 183402294
Test: manual:
* atest CtsAutoFillServiceTestCases:InlineLoginActivityTest\
--iterations 5
* Force gc: adb shell kill -10 $(adb shell pgrep ext.services mockime\
system_server -d '\ ')
* Rerun that a couple of times so the binder objects get cleared.
* Check for leaks of autofill.Session in system_server and
SurfaceViews or RemoteAccessibilityEmbeddedConnection in
com.android.cts.mockime.
Change-Id: I5447b173313919507969872bdeb7ff3038152c23
ie: due to BadTokenException or InvalidDisplayException
Previously, only views that were already in the viewhierarchy
before attempted to be re-added would be removed. This makes
sure if the view was newly added, it'll also be removed.
This prevents a memory leak of views.
Test: manually show and cancel multiple toasts,
check the hierachy viewer that no Toast views remain
Fixes: 234694098
Change-Id: I06bbae70c277d0615753edc9ec0a8e7439ad7020
Apps can cancel draws using the PreDrawListener. When this happens during a sync request, we don't allow another draw to happen since we are trying to avoid multiple draw requests until a sync is complete.
This change makes sure we can draw once before respecting the cancelDraw flag sent from WMS. So even if WMS says it can't draw again, we will allow retries if the cancel happened due to PreDrawListener
Test: Apps that cancel draw don't get stuck during sync
Fixes: 236910512
Change-Id: I67742d03b78306855e258f06c1496b2ba29ca74e
The private flag to let the layout system know the bar should extend its
requested size by the cutout size is not included in the insets
calculation, and the bar size will have a mis-match if they want to do
so. To modify the calculation of the insets to make them match.
Bug: 236101339
Test: See the bug
Test: atest DisplayPolicyInsetsTests
Change-Id: If76f3325196db7e8ab90d6dc56c9f67e0cd61ca9
This reverts commit:
db407ef12d, and
d8aa7f7882.
Reason for revert:
The surface size would be reduced by mTranslator unexpectedly.
Fix: 233017734
Test: Open a legacy app which has CompatibilityInfo.SCALING_REQUIRED
and see if the app is cropped.
Change-Id: If830866328a5709cf6856fe840a804b304052003
The attached frame is the frame of the parent window that its child
attaches to, as long as the child is not
TYPE_APPLICATION_ATTACHED_DIALOG. It is a factor while computing the
window frame.
Previously, we let the child obtain the attached frame from its parent
view root. However, if the parent and the child are not in the same
process, it can be tricky.
This CL sends the attached frame from the server to the client via
ClientWindowFrames. In this way, the child can compute its window frame
without having to accessing the parent view root.
Bug: 161810301
Bug: 175861127
Test: atest ActivityRecordTests WindowLayoutTests
Change-Id: Ia844a4c927027e305a56114216eaee2bf7933b1f
When the enableOnBackInvokedCallback is set to false (or not set),
registering an OnBackInvokedCallback should be a no-op to avoid
overriding the default compat callback.
Test: Manual testing registering a callback on an app with the flag
disabled and doing a back gesture. Currently we don't have test
executing a back gesture so automated tests are not possible
Bug: 235206960
Change-Id: I54d843f11130a78ed5a68cbe4722e601a2086ee1
Merged-In: I54d843f11130a78ed5a68cbe4722e601a2086ee1
(cherry picked from commit aa48dc3c2d)
