...in order to closer match our mental model of what we consider
a window to be visible.
Bug: 118118435
Test: adb shell dumpsys window visible while status bar hidden
Change-Id: I4247eb2d52ddbd07c38824300965d7499b99848f
Our code no longer lives in that package and eng. prod. team is
spamming folks with test failures because we are listed in the
OWNERs file.
Bug: 0
Test: N/A
Change-Id: I68b200d4de6fcfbaab218325fd0e19353d9ba611
* This is to incorporate the API council feedback at b/148107416
* This is made possible by the new DataClass codegen version 15
Test: build
Bug: 148107416
Change-Id: I8adaf45a64bc08e73988d61fba56430f2b49f747
Since disabled changes are disabled by default, our policy should allow
opting in to them in the final release.
Add toString to OverrideAllowedState for easier test debugging.
Test: atest com.android.server.compat.OverrideValidatorImplTest
Bug: 144552011
Change-Id: Iff01ee44d30d3e5703a980cddaf1b38435756c3c
1) System window inset bottom now includes IME height, so we were double counting the IME. Changed to stable inset (this is what PIP uses).
2) If you dismissed the stack while IME was up, we didn't tell the stack view when IME goes down since there were no bubbles. This meant you couldn't place bubbles where the IME used to be.
3) Flyout wasn't animating with the stack when avoiding IME. Changed to animate the flyout.
Test: 1) Open IME, observe you can drag bubbles in the expected locations
Test: 2) Dismiss bubble stack with IME up, close IME, observe you can drag bubbles where the IME used to be.
Test: 3) Move stack to bottom of screen, add new bubble and quickly open IME, observe flyout animates up, close IME, observe flyout animates back down.
Fixes: 141780462
Change-Id: Ied1d6da1edf946ca338bd908e52a3863c90ffd5a
We handle changes to the leashes from the UI thread, but use
the same SurfaceControl wrapper object from the RenderThread with
SyncRtSurfaceTransactionApplier. This means that at the time
we release a SurfaceControl from the UI thread we might have already
scheduled a SyncRtSurfaceTransactionApplier to use it, and actually
that could be in the process of running, leading to racy access and
crashes. To fix this we release the SurfaceControl from the RenderThread
so that it happens behind all existing operations.
Bug: 151086678
Test: Existing tests pass.
Change-Id: I2308d1c64f3f368c32587f99ddfb9e05955f821f
It could be called with global WMS lock held.
Bug: 150770486
Test: atest FlickerTests
Test: atest ApplicationExitInfoTest
Test: atest CtsAppExitTestCases:ActivityManagerAppExitInfoTest
Change-Id: Ic94fdbf4f8718245f5b0f25c41a2596a16841b0e
Made an actual class for the imecontroller in divider to
prepare for some more complicated interactions. Also consolidated
the minimize/resizability update logic for the same reason.
Bug: 150781668
Test: no change. things should work and tests pass
Change-Id: I68f1b47e092ed35311cbcd2878e4c271ac161a8c
In cases where we are replacing the client surface transparently (e.g.
preserved surfaces), we call reparentChildren to move client added
Surfaces of the preserved Surface to the new Layer. However we are calling
this on the WSA layer, and so we end up reparenting the BLAST Surface
to the new layer. But since we always construct a new BLAST surface on the
WM side, we end up with 2! Rather than try and juggle about when we need
to or need not to construct a BLAST surface and reparenting them across
preservedSurfaces, it seemed either to just use the BLAST surface as the
root of the reparentChildren operation.
Bug: 150013915
Test: Enable BLAST, use split-screen
Change-Id: I1357200b41d183c2331b684ff636dd40a3b98168
