The feature is punting to QPR1, disable feature by flag first. The
feature will strip from the build in the follow up change.
Bug: 190030331
Test: manual. Clear flag and make sure the feature is disable.
Change-Id: Id5e0efeff0465890a5d26ef10b6e54359f569317
Re landing with the following changes:
We initially cloned the SurfaceControl handle to avoid locking when
accessing the SurfaceControl from the position listener callbacks
running from RT workers. But this meant the last reference to the
layer handle would only be released by GC. If SurfaceViews are
created and destroyed rapidly, we would be at the mercy of GC to
release buffers.
Original change:
There are three transaction queues that can submit SurfaceView
changes.
1. Buffer updates via BBQ apply token
2. SCC apply token
3. ViewRootImpl BBQ apply token
It makes sense for most SurfaceView changes to be synchronized with
ViewRootImpl draws since the caller can optionally synchronize the
change with main window content.
This change eliminates the tmp transaction that is applied directly
via the SCC apply token and instead applies them with the ViewRootImpl
draw transaction.
Also take the opportunity to scope down mSurfaceControlLock usage.
Test: atest SurfaceViewSyncTest
Test: go/wm-smoke
Test: run mem tests via forrest
Bug: b/217973491, b/221631942
Change-Id: Idba712d146e62d7346920dc4f060cba92d47fada
Content recording relies upon a class describing current state.
rather than passing around details from media > display > wm.
WMService keeps track of the session in ContentRecordingController.
ContentRecordingController manages hand-off between different
DisplayContent instances, as the session details are changed.
Manually tested that fold/unfold handling when screen recording
from QS tile still works, and that taking over a screen cast
with a screen recording works.
Refactoring logic from DisplayContent into new recording
delegate will come in a future change.
Bug: 216756854
Test: atest FrameworksCoreTests:ContentRecordingSessionTest
Test: atest WmTests:DisplayContentTests
Test: atest WmTests:ContentRecordingControllerTests
Change-Id: Ib4f125dd703d362ac13fcbe469d00b345827e706
Modified SurfaceView and ViewRootImpl to provide callbacks when syncing
a transaction instead of sending transactions. This will ensure a clear
ownership of the transaction object since it will be provided in the
callback when BBQ adds a buffer into the transaction. Modified JNI to
add compatibility for native functions.
Test: Manual testing from go/wm-smoke.
Test: BLASTBufferQueueTest
Bug: 210714235.
Change-Id: I1f872d6b2846b0d64d5b33b8866d0b2ec7126c8c
Originally, View was implementing onBackInvokedDisptacherOwner, but now
only Activity and Dialog and since back event are related to the
window, it makes sense to move them into the android.window package
This follow up comment at:
ag/c/platform/frameworks/base/+/16764116/comments/e131f3ef_e3e1d2e0
Test: atest BackNavigationTests
Bug: 221401221
Change-Id: Ia2f26162beb6a41b6e162b31e599e882f8bf7320
Mark/unmark Views as keep clear areas as they gain/lose focus
with a small delay.
Test: atest KeepClearRectsTests
Bug: 218494300
Change-Id: I33c89b5d2ed6707f95eca8ec4b5604c9193aec05
Since ViewParents can be set to not clip their children, custom
keep clear areas can extend beyond the bounds of its hosting View.
If preferKeepClear is set, add the View's bounds as a keep clear area,
but also keep the custom Rects.
Bug: 221073574
Test: atest KeepClearRectsTests
Change-Id: I85a4e4a223fbba787c5afebf2689a031243808d4
Ensure one-shot, scheduled Transactions are closed after application.
While individual Transaction instances aren't all that heavy, this
avoids unnecessary GC pressure and churn.
Bug: 216159702
Test: atest WmTests SystemUITests FrameworksCoreTests
Change-Id: Iec053dd8163fb9b300fd1e9eb9f1472a0d0dd782
After a user perform a11y action, namely moving up/down/left/right, we
have to disable tracking focus functionality.
We refactor #onDrag to a more general term #onMove to cover any move
action which has to disable tracking focus functionality.
Bug: 218935435
Test: atest WindowMagnificationTest
atest WindowMagnificationControllerTest
atest WindowMagnificationManagerTest
Change-Id: I578b301645a08c71e874fe2f4fcf2557202abefd
For following typing focus feature, we add a
moveWindowMagnifierToPosition method for a window magnifier to move it
to the center of onRectangleOnScreenRequested.
Apart from calling this method to fulfill movement functionality, we can
separate the movement from calling enableWindowMagnification which is a
temporary replacement for movement functionality. Therefore, we can
distinguish whether the it is enabled by the first time or the further
movement behavior. It would help us differentiate the condition whether
we should reset the following typing focus to on/off state. (b/216394179)
Bug: 219654280
Test: atest IWindowMagnificationConnectionTest
atest WindowMagnificationTest
atest WindowMagnificationAnimationControllerTest
atest WindowMagnificationControllerTest
atest WindowMagnificationConnectionWrapperTest
atest WindowMagnificationManagerTest
Change-Id: Iaac3ca6868d948571c1aee54a5f122c9697059d8
This patch introduced a new private flag
PRIVATE_FLAG_LAYOUT_SIZE_EXTENDED_TO_CUTOUT to let the window extend
it's requested window frame to contain the display cutout frame. This
is useful for the case of navigation bar. Without it, the navigation
bar may not have enough space to layout it's content when it's on the
same side as the display cutout. With the flag set, the Navigation
bar will have the requested size plus the navigation bar size as its
frame.
Bug: 203031262
Bug: 161689946
Test: See reproduce steps in b/203031262
Test: atest WindowLayoutTests
Change-Id: Id1d6f09dc421b5f25e16e4aca6282b6deec2e8c4
This CL allows applications to choose whether to set restricted or
unrestricted keep-clear areas by adding a dedicated SystemApi for
unrestricted keep-clear areas - View#setUnrestrictedKeepClearRects. The
SET_UNRESTRICTED_PREFER_KEEP_CLEAR_AREAS permission is now only checked
for keep-clear areas from that API
Bug: 221094507
Test: atest CtsWindowManagerDeviceTestCases:KeepClearRectsTests
Test: atest WindowStateTests#testUnrestrictedKeepClearAreas
Change-Id: I89ca3149117b4d457c5521d617880870706d7793
For legacy recents animation, launcher side use
RecentsAnimationController#setAnimationTargetsBehindSystemBars to
callback if the animating recents task target is valid to affect
system bar apparence according the gesture threadshold.
if the animating recents task is behind system bar, means the
gesture threshod not yet passed and the task still can affect
system bar apparence, and vice-versa.
with shell-transition, since launcher triggers recents animation
by normal startActivity without initiating RecentsAnimationController
with startRecentsActivity, the launcher will be top-resumed
(but the surface hierarchy the recents task is still be top-most) when
starting gesture on navbar, in this case, launcher can affect the
system appearence even though launcher is behind systembar.
beside, previously we also rely on setAnimationTargetsBehindSystemBars
to hide soft-keyboard in multi-windowing mode when quick-swich tasks,
without this, soft-keyboard will keep visible when swiping up to
recents.
As the result, we needs to backport the most logic of
setAnimationTargetsBehindSystemBars for fixing the above cases,
the only difference is we renaming the method with
setRecentsAppBehindSystemBars(behindSystemBars) to only set recents app
can affect systembar apparence, and placing hide IME/IME icon logic into
handleLegacyRecentsStartBehavior when starting recents animation.
Fix: 215504556
Test: manual as below CUJs with enabling shell-transition:
CUJ1:
1) Launching a app with showing IME
2) Quick-switching to the next task or swiping task to home
3) Expect no navbar icon flickering
CUJ2:
1) With entering split-screen and showing IME on the split task
2) Swipe up to recents
3) Expect IME shound be hidden
CUJ3:
1) Launching a app
2) Hammer tapping on the navigation bar
3) Expect the staus bar icon won't blinking
Change-Id: I552eea738aed5566eb897bb9c68507e83ac43e1d
Add Syncer class that allows callers to add desired syncs into a set and
wait for them to all complete before getting a callback. The purpose of
the Syncer is to be an accounting mechanism so each sync implementation
doesn't need to handle it themselves. The Syncer class is used the
following way.
1. SurfaceSyncer#setupSync is called
2. addToSync is called for every SyncTarget object that wants to be
included in the sync. If the addSync is called for a View or
SurfaceView it needs to be called on the UI thread. When addToSync is
called, it's guaranteed that any UI updates that were requested before
addToSync but after the last frame drew, will be included in the sync.
3. SurfaceSyncer#markSyncReady should be called when all the SyncTargets
have been added to the SyncSet. Now the SyncSet is closed and no more
SyncTargets can be added to it.
4. When all SyncTargets are complete, the final merged Transaction will
either be applied or sent back to the caller.
The following is what happens within the SyncSet
1. Each SyncableTarget will get an onReadyToSync callback that contains
a SyncBufferCallback.
2. Each SyncableTarget needs to invoke SyncBufferCallback#onBufferReady.
This makes sure the SyncSet knows when the SyncTarget is complete,
allowing the SyncSet to get the Transaction that contains the buffer.
3. When the final FrameCallback finishes for the SyncSet, the
syncRequestComplete Consumer will be invoked with the transaction
that contains all information requested in the sync. This could include
buffers and geometry changes. The buffer update will include the UI
changes that were requested for the View.
Test: SurfaceSyncerTest
Test: SurfaceSyncerContinuousTest
Bug: 200284684
Change-Id: Iab87bff8a0483581e57803724eae88f0a3d96c8e
We have paused and thus flushed the HW renderer before calling relayout for many releases.
This has served a multitude of purposes over the years:
1. Ensuring that the WM doesn't destroy the surface or update the
default buffer size while we are rendering - WM no longer updates
default buffer size or handles surface lifetime
2. Ensure that we can get a proper frame number, previously used for
deferTransactionUntil - deferTransactionUntil doesn't exist anymore
3. Ensure that we can call setNextTransaction at an appropriate time
- We now call this from an RT thread side callback.
This means in the current code we only have to pause it when we ourselves are updating the size. Since this pause requires all previous draws to flush, it should be a nice performance win.
Test: Existing tests pass
Bug: 220649859
Change-Id: I143de3f44b8bd69754d9e824fc8b729dc296e183
This is a semi-automatic change.
See https://errorprone.info/bugpattern/JdkObsolete for the rationale.
Test: make
Bug: 221046110
Change-Id: I15328005007ddc58f56604f6064c30fbed2c01a6
(cherry picked from commit 1c8715261d)
Merged-In:I15328005007ddc58f56604f6064c30fbed2c01a6
We first need to dispatch insets, then we can measure so we don't
need to immediately measure again.
Fixes: 210881360
Bug: 190379081
Test: Presubmit, Boots
Change-Id: Id40a083dd2e122ca71a96213e94b5bbbb45d596d
