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
This reverts commit 0de71ca543.
Reason for revert: Don't yet have a use for the definitions, and will likely reimplement them differently.
Test: Is a reversion.
Change-Id: I99a71551069069d117039af4708030772b741cea
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
