- If a window has PRIVATE_FLAG_LAYOUT_SIZE_EXTENDED_BY_CUTOUT, the final
frame might be larger than the requested size, and we cannot use the
requested lengths to compute the window frame. Because the window size
will be the new requested size, we don't want to extend the window
size again and again.
- When we are checking if a frame is overlapped with the display cutout,
we only need to check if displayCutoutSafe contains the frame. We
don't need to check individual bounding rectangles. This also fixes an
issue that the gestural navigation bar is not extended by the
waterfall cutout because it doesn't have bounding rectangles.
Bug: 203031262
Bug: 161810301
Test: Enable double cutout or waterfall cutout in developer options and
see if the frame of navigation bar is correct when it is at the
same side of the cutout.
Change-Id: Ic8c090198c556f2dc3b2c0b8498c42e9ca18c795
Fix: 217730256
Bug: 222537368
Test: Added test in EditTextTest (will merge later when reviewed).
Merged-In: I78354a0f1d955c5b7c1ead044ea49086b3479841
Change-Id: I78354a0f1d955c5b7c1ead044ea49086b3479841
(cherry picked from commit e1f392d171)
This reverts commit 0de71ca543.
Reason for revert: Don't yet have a use for the definitions,
and will likely reimplement them differently. This is an adjusted
revert to account for a resource finalization error
Test: Is a reversion.
Bug: 222537368
Merged-In: I99a71551069069d117039af4708030772b741cea
Change-Id: I99a71551069069d117039af4708030772b741cea
(cherry picked from commit 65e5bf07c2)
These warnings triggered on ag/16873530. The warnings are like:
[AndroidFrameworkRequiresPermission] Method addKeyguardLockedStateListener() annotated {allOf=[android.permission.SUBSCRIBE_TO_KEYGUARD_LOCKED_STATE]} but too wide; only invokes methods requiring [none]
public void addKeyguardLockedStateListener(@NonNull @CallbackExecutor Executor executor,
^
If calling an AIDL interface, it can be annotated by adding:
@JavaPassthrough(annotation="@android.annotation.RequiresPermission(...)")
Bug: 216630470
Test: n/a
Change-Id: I479063de6b591da44c474e4aa93e0466104d2a9a
Use the android.os.InputConfig flags to control input window behavior in
InputWindowHandle. This consolidates the old boolean flags and
inputFeatures flags into one set of flags so that the InputConfigs are
the sole set of flags that change change how an input window behaves.
After this change, InputFeatures and LayoutParamsFlags are specific to
WM, which is responsible for converting them into InputConfig flags.
Trivial conversions between these flags are done in InputConfigAdapter.
The LayoutParams type and flags are still part of the this API to send
these attributes to native code. However, they are no longer used by
input.
Bug: 216806304
Test: manual: verify touch functionality
Test: atest WindowStateTests
Change-Id: I5b384770272c111680783ee8ab01ecd6e03f42be
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
InputFeatureFlags are now a WM-only flag, but is temporarily used by
InputWindowHandle until the cleanup is completed.
Bug: 216806304
Test: atest libgui_test
Test: atest inputflinger_tests
Change-Id: I1260431e99d2c50261dc8b0356dc3e21ba76d39f
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
Introduce stylus handwriting settings and check if its enabled before
calling IMM#startStylusHandwriting()
Bug: 219777744
Test: atest StylusHandwritingTest
Change-Id: Id58b2eb66a0a1178743d08921918f3d9d717546c
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
