New API provides all maximum WindowMetrics, for all
possible rotations in each DeviceState. This information
allows launcher apps to determine different device
layouts ahead of time, without having to reload the
grid model on every device state change (fold/unfold).
Done:
* WindowManager calculates bounds for the given display, in
possible rotations
* Defining API surface
Not started:
* WindowManager calculates insets for each rotation
* Display stack builds collection of DisplayInfo, for all
possible display states (folded, unfolded)
* Display stack pushing set of DisplayInfos to WindowManager
Bug: 181127261
Test: atest FrameworksCoreTests:WindowMetricsTest
Test: atest FrameworksCoreTests:WindowInsetsTest
Change-Id: Ic4580f9c1ee919e5e93cd96b8f11c743fa42f9f1
Hold the surface control lock in PositionUpdateListener
callbacks before checking if the SurfaceControl will
be null. UI tread might release it after the checks
causing crashes.
Also fix a case where the ViewRootImpl may be null
in the positionChanged callback.
Bug: 199261027
Test: run steps in bug
Test: go/wm-smoke
Change-Id: I5a4cac35fe14356389b29268fddf9703b25c03aa
Added new APIs to DisplayManager to:
1. set the user preferred display mode,
2. clear user preferred display mode and
3. wheteher user has chosen a display mode
These new settings are stored in Settings.Global.
Bug: 192332479
Test: atest DefaultDisplayModeTest
Test: atest LocalDisplayAdapterTest
Change-Id: I3a60e271c7ec23c84e74487e89b3e29ca91e8a40
New API provides all maximum WindowMetrics, for all
possible rotations in each DeviceState. This information
allows launcher apps to determine different device
layouts ahead of time, without having to reload the
grid model on every device state change (fold/unfold).
Done:
* WindowManager calculates bounds for the given display, in
possible rotations
* Defining API surface
Not started:
* WindowManager calculates insets for each rotation
* Display stack builds collection of DisplayInfo, for all
possible display states (folded, unfolded)
* Display stack pushing set of DisplayInfos to WindowManager
Bug: 181127261
Test: atest FrameworksCoreTests:WindowMetricsTest
Test: atest FrameworksCoreTests:WindowInsetsTest
Change-Id: Ic4580f9c1ee919e5e93cd96b8f11c743fa42f9f1
A11yAction#ACTION_DRAG_START.
This allows the system to run a11y-specific code
and still accept drags via touch events when a11y is
enabled.
Test: builds
Bug: 26871588
Change-Id: I40e8f1adf5b773c8fa02173cbd96aa5e9ed54a4d
Currently, we only allow translation for the resumed Activity. It
works fine for full screen Activity. On foldable devices, we may
have two Activity in the same time. It is possible one Activity is
on the paused state but there is still new incoming message, we
should also allow the message can be translated.
Bug: 199264898
Test: atest CtsTranslationTestCases
Test: manual. Use one Activity targetsdk prior to Q then receiving
broadcast to start Ui translation on paused state in split mode.
Change-Id: I6720b41d9995c9ced2e3b2b87eb95540101d15a0
flushShadowQueue no longer does anything in BBQ so remove from Java and
JNI code.
Test: Builds
Fixes: 199204968
Change-Id: I4df67a23732ba4ffaca42390b29d3f81cadd6457
It's possible for a caller to requested mergeWithNextTransaction, but
the main frame had nothing new to draw. If that's the case, the
mergeWithNextTransactions will be stuck and never applied (or applied
much later). Since this could end up blocking Transactions, it's better
to force apply these when we know a frame wasn't going to draw this
vsync.
Test: Existing tests pass
Bug: 195262673
Change-Id: Ic0919ba6446d6a12d824185f6b3e540c2d5319d7
- If the taskbar is collapsed and isn't providing full insets to the
app, we still want the IME to be inset for the nav button that shows
Fixes: 197727397
Test: Collapse taskbar, open IME
Change-Id: I9f2367344385c9a23e2d6323637a0b2d1713b169
The previous code waited for a frame complete callback from hwui before
notifying WMS that a draw had occurred. However, frame complete callback
was not guaranteed to get called since it only invokes a callback if a
draw actually occured. VRI really needs a signal that RT has completed,
since it just needs to know that a draw was possible so it can notify
WMS that the RT completed its pass.
Instead, rename frameCompleteCallback to frameCommitCallback since that
API is exposed to a public API when a frame was actually drawn.
Create a new callback, frameCompleteCallback, that is invoked when the
draw has completed, regardless if a frame was actually drawn.
When the frameCompleteCallback is invoked, VRI can check to see if a new
frame actually drew. VRI can call into BBQ to see if the frame acquired
matches the frame that was attempted to draw. If so, VRI can wait on a
transaction callback. If not, it can allow VRI to continue. In either case,
it will notify WMS that the draw has finished.
Test: Split over and over
Bug: 195262673
Change-Id: I24dd19ab2746be3fc33e597761abf8c5249f8b5b
SurfaceView clients may hold on to surface references. In S this means
they would extend the lifetime of the SurfaceControl resulting in
"leaking" buffers until the references are cleared or the app is
terminated.
Fix this by calling a new destroy function on Surface which will
explicitly remove references to the SurfaceControl and BBQ it holds.
This is safe because SurfaceView controls the lifecycle of the Surface
and knows when the Surface will become invalid. Once invalid, the Surface
cannot become valid again.
Test: repro steps in bug
Bug: 198133921
Change-Id: I5c7e43736f025fc0965eae2f19719ba40df3cb70
Merged-In: I5c7e43736f025fc0965eae2f19719ba40df3cb70
It is a public interface which should not have different versions
sharing the same API level. This CL moves the methods to an
@hide interface.
Fix: 198614722
Test: atest android.signature.cts.api.current.SignatureTest
Change-Id: Ib02708aeb1ec960bda20b6b60d4df6f0c9b4d9d6
* changes:
Dump WindowContainer SurfaceControls to proto
Dump SurfaceControl's layerId to proto
Expose SurfaceControl's native mLayerId property to Java
- This ensures that the caller can synchronously initialize the existing
displays without waiting for the onDisplayAdded() callback, which can
happen asynchronously (since the callback is oneway).
Bug: 196186963
Test: atest WMShellUnitTests
Test: atest ActivityTaskManagerServiceTests
Change-Id: I0a8d5f9b4ede7b487a8de14bdb6eaacae7d03d9f
Currently, SurfaceView#setChildSurfacePackage only reparents a
provided SurfacePackage when there is no SurfaceControl already
present. This can lead to the SurfacePackage potentially never
being reparented.
This changelist addresses the issue by always reparenting the
SurfacePackage, following cleanup of the existing
SurfaceControl.
Bug: 197568243
Test: atest SurfaceControlViewHostTests#testCanReplaceSurfacePackage
Change-Id: Ib0bcfee5cb9801e1b1c4f1f300af9862141b12f3
