- Helps clarify what the surfaces are in the registry when dumping
Bug: 266978825
Test: dumpsys activity service SystemUIService WMShell
Change-Id: Ifd34bb2977e1a8c1a1ef9fcaaaa3e3677ec35f9b
We'll send an onBackCancelled() event whenever the top callback is in progress and has been removed from the callbacks.
Changes:
- We send onBackCancelled() and reset the ProgressAnimator when clear() is called.
- Added a check to avoid sending an onBackInvoked() to the app if the ProgressAnimator is not in progress.
Test: atest WindowOnBackInvokedDispatcherTest
Bug: 255324784
Change-Id: I0dcc1fb869070dd5bab6c0802c933783266594e5
Final keyguard state is computed in KeyguardController and passed
through Transition flags to SystemUI for occlude status as well as
(previously) visibility during unlock.
The occlude state cannot be derived only from ChangeInfo items in the
transition.
Example 1: b/284096414 where an app launches two activities, one opaque
and the second translucent. Closing/unoccluding the translucent activity
leaves the opaque activity on screen. This should not be recorded as an
unocclude, but all Keyguard sees in the Change diff is an OCCLUDE
activity closing and nothing new opening.
Example 2: b/282672298 in which a shared-element return transition from
Photos to Camera generates two separate transitions: one for re-opening
Camera, and a second for closing Photos. Because the final transition
was for a closing OCCLUDE activity on its own, all Keyguard could
interpret this as was a request to unocclude the keyguard and play the
return-to-keyguard animation.
These cases are fixed by the final state being sent after the transition,
but the intermediate animation was wrong and showed the lock screen
views for a few hundred milliseconds.
We also introduce one more flag in opposition to KEYGUARD_GOING_AWAY,
which is the flag KEYGUARD_APPEARING. This is used to wrap up
swipe-to-unlock interactions which end with the device locked, since
swipe-to-unlock optimistically generates a full transition for the
unlock and to avoid jank we have to merge an inverse transition back in.
Bug: 284096414
Bug: 282672298
Fix: 282302169
Fix: 282291585
Change-Id: Ib2c7acdace63729dd52711e47c8cc481eac45ebe
This CL also refines the debug strings of TRANSIT_TO_FRONT and
TRANSIT_TO_BACK to make the naming rule consistent.
Fix: 283076194
Test: Swipe to home from a landscape app and quickly open it again. See
if the home screen is on top of the app during the transition.
Change-Id: Ic8dba8c19e2447d8192898642d8499dec2a344c3
Robolectric mocks out `HandlerThread` in such a way that in certain instances `HandlerThread.getLooper` returns null. Since adding the null check is small enough, we can opt to make this change to allow robolectric tests to run.
Test: atest ClockworkSettingsRobotests
Bug: 237804605
Change-Id: Ib28f80413265a770cfac44cf451714f1b66dfbc8
...when aspect ratio not match from snapshot bounds to window frames.
To reduce the chance of misjudge crop size.
Bug: 283099593
Test: quick switch the app which won't draw navigation bar but need
letterbox.
Change-Id: Ideb84bc35391b550896debd270adc59f7af7719f
- Currently, a display change while recents transition is playing will
result in the display change being applied prior to the recents
animation playing, which means that the transition-end snapshots are
taken in the wrong display configuration
- Instead, When a display change is requested mid-recents transition,
cancel the current transition and record the snapshots in place
(this matchs legacy recents animation behavior)
- Separately, if the snapshot is requested & recorded mid transition,
then we can ignore the post-transition screenshot (which would be
wrong in the display change case, or just extraneous even in the normal
case where launcher has requested a screenshot itself already).
We do this by comparing the time that the last snapshot was taken
with the start of the transition.
Fixes: 278189494
Test: Go into Overview and rotate the device and observe the task views
Change-Id: I985cd9c852a326027ae3ab4f7ffe837431d1c654
This shouldn't be necessary, but it acts as a failsafe in case
a previous transition messes-up visibility in its finishTransaction.
Bug: 280737703
Test: launch app, swipe-to-home, relaunch the app before home animation
finishes.
Change-Id: Ic7a81e313b35310061c9278ea72c98cc0bf20ef7
When an OnBackInvokedCallback is unregistered from a WindowOnBackInvokedDispatcher, it is important to check if the callback is the current top one and if the back animation is in progress. If it is, we should call onBackCancelled() on the callback as a final step.
Test: atest WindowOnBackInvokedDispatcherTest
Bug: 276816667
Change-Id: Icaf98899c474c4e8d89d4a9c77acc309d37e9582
In VRI, SSG are sometimes created as a way to notify WMS that a buffer
has been drawn and not always to sync the buffer. In those cases,
there's no need to prevent overlapping syncs since the buffers cannot be
submitted out of order. Only add the safeguard SSG when there's a buffer
getting synced to ensure multiple buffer syncs for the same VRI are
submitted in order.
Test: SurfaceSyncGroupTests SurfaceSyncGroupTest
Bug: 279096620
Bug: 279790175
Change-Id: I77841296297717e413237c183738b9ec9642f1cf
When letterbox is repositioned, window configuration bounds are changed.
Because we currently only report public config changes in
diffPublicOnly, the client doesn't report changes in window
configuration.
We should always report window configuration bounds change to notify
that the position of window has changed.
Bug: 262900133
Test: atest FrameworksCoreTests:android.app.activity.ActivityThreadTest
Manual test with app in bug
Change-Id: I9fc10876c03933ac8aac05205d56ad6537df72a8
When SSG's complete, they send the Transaction to their parent which
could live in another process. This can be problematic if the parent
process has higher privilege than the child and the child added
something into that transaction that only privileged processes can call.
Therefore, sanitize transactions as they cross binder using the calling
uid and pid in case the calling process does have the correct
privileges.
Test: Coming...
Bug: 267794530
Change-Id: Ic0dd2619c22afe57c673c9484b526b841ef1ac99
This is useful for tests that adds an transparent overlay and wait for
its readiness.
Bug: 226803477
Test: CtsWindowManagerDeviceTestCases:SurfaceControlViewHostTests CtsWindowManagerDeviceTestCases:WindowInputTests
Change-Id: I59ede5a38b729c756abc32fd682ef2d132098533
This was being ignored, but we should plumb the information
through so that the defaulthandler doesn't apply an animation
on top of the scene-transition (which expects a jumpcut).
Bug: 190806800
Test: take screenshot, then pres edit button
Change-Id: Ib1bda6220012cf3b8f85fccac4cc50e1327b9886
Previously, when synchronizing IME visibility in between removing
tasksnapshot with IME starting window and showing the real IME during
the activity launching, we schedule a runnable for removing the starting
window with a timeout (600ms) if IME will be shown when
AR#onFirstWindowDrawn comes, and then remove it immediately once
the IME has actually drawn before that timeout.
But this approch doesn't accurate when the activity was in fixed
rotation. Since the IME client visiblity change from InsetsController
does not aware the IME orientation was still in changing (portrait ->
landcape), in this case, starting window will be removed in earlier
stage and seeing IME fade-out / fade-in animation during
AsyncRotationController controlling IME surface in fixed rotation.
To more accurate deciding whether to defer the starting window
removal during the rotation, in this CL
1) Modified StartingWindowRemovalInfo#deferRemoveForIme with
deferRemoveForImeMode to diffenciate scenarios for giving adaquate
waiting IME drawn timeout:
- DEFER_MODE_NONE: no need wait for IME drawn.
- DEFER_MODE_NORMAL: wait IME drawn at most 600ms
- DEFER_MODE_ROTATION: wait IME rotation and drawn at most 3 secs.
2) Fix StartingWindowRecordManager#removeStartingWindow removes the
record from mStartingWindowRecords too early before calling
onImeDrawnOnTask leads to the the IME snapshot starting window
always be defered to remove after the timeout.
3) Modified ImeInsetsSourceProvider and AsyncRotationController to
skip reporting IME drawn state to WMShell when the system was in
fixed-rotation, and report it once AsyncRotationController receiving
onAnimationFinished callback from IME token's surfaceAnimator.
4) Added a flicker test to verify this CL works as expected for this
use case.
Fix: 268627602
Test: atest FlickerTests:\
ShowImeOnAppStartWhenLaunchingAppFromFixedOrientationTest
Test: atest ActivityRecordTests
Change-Id: Ie476e89a57f2f64d4d66e722fedeeb1719d9de55
The `ActivityInfo` should not be `null`, otherwise we will not be able to check if the activity has the `enableOnBackInvokedCallback="true|false"` flag.
Unfortunately, there is no good default value in this case.
Our options are:
- Use the application flag, but this may cause random behavior that is difficult to troubleshoot.
- Assume that the activity has `enableOnBackInvokedCallback="false"` in the manifest, which might have strange behavior but at least it would be a "known issue" (for example, if you activate predictive back and it doesn't work in that activity, you can check that XYZ is correct).
Regardless of the reason, I would add a warning or error message explaining the problem.
Test: mp droid
Bug: 271860402
Change-Id: Ie91376ce18eb0a8d5528339a68e4db88a57cff86
Screen rotation should be display-native to round trip properly during
the animation, but other use-cases like recents will perform an
intermediate composite into SDR before being displayed, in which case an
HDR screenshot will tonemap better.
Bug: 242324609
Bug: 276812775
Test: Rotation animation
Test: Switch apps with recents
Change-Id: Idd25acea9ceffa19d7bf16b871132e87d16791d7
The shell-transition player "Transitions" only supported
playing one animation at a time. It supported limited
support for concurrent animation via `merging`, but this
is for specific/curated situations. Since support via
merge is complicated, there weren't many implementors and
instead, by default, animations would just jump-to-end
to allow the next animation to start immediately (to
minimize perceived latency).
Unfortunately, if there are TRULY independent transitions,
this mechanism is unweildy as it'd require adding support
for any incoming transition into any active animation.
This CL moves the existing queue/merge mechanism into a
"track" and then adds support for multiple tracks to play
simultaneously. This way, for transitions which aren't
independent, the mechanism doesn't change; however, for
truly independent transitions, their corresponding
animations can also run independently.
The expectation is for WMCore to assign track ids to
transitions. Then the player (Transitions.java) can
use this information to either play them in parallel
or, in the future, do some type of merging on its own.
The default is that, all transitions with the same
track-id will play in the same track and serialize
with eachother -- but otherwise the tracks are independent.
There may, however, be some situations where a transition
might conflict with more than 1 track. In this case,
we just fall-back to a global "SYNC" and basically wait/
flush all the running animations/tracks before starting.
Supporting anything fancier is not worth the effort since
this situation isn't likely to be very common.
This SYNC is actually implemented by just generalizing the
existing SLEEP failsafe mechanic. We now just treat an
incoming SLEEP the same as SYNC.
Bug: 277838915
Bug: 264536014
Test: atest ShellTransitionTests
Test: this change, alone, should be a no-op so existing tests too.
Change-Id: I97ca21e0917be884cac105a6cb2d2c656f0e4207
This change will ensure that if multiple SurfaceSyncGroups are created
for the same ViewRootImpl the SurfaceSyncGroups will maintain an order.
The scenario that could occur is the following:
1. SSG1 is created that includes the target VRI. There could be other
VRIs in SSG1
2. The target VRI draws its frame and marks its own active SSG as ready,
but SSG1 is still waiting on other things in the SSG
3. Another SSG2 is created for the target VRI. The second frame renders
and marks its own second SSG as complete. SSG2 has nothing else to
wait on, so it will apply at this point, even though SSG1 has not
finished.
4. Frame2 will get to SF first and Frame1 will later get to SF when
SSG1 completes.
The code ensures the SSGs that contains the VRI maintain an order. What
happens here is we create a new SSG that's a placeholder. Its only job
is to prevent a SSG from completing. The active SSG for VRI will add a
transaction committed callback and when that's invoked, it will mark the
placeholder SSG as ready. If a new request to create a SSG comes in and
the placeholder SSG is not null, it's added as part of the new active SSG.
A new placeholder SSG is created to correspond to the new active SSG.
This creates a chain to ensure the latter SSG always waits for the former
SSG's transaction to get to SF.
Test: SurfaceSyncGroupTests#testOverlappingSyncsEnsureOrder
Test: WmTests:com.android.server.wm.SurfaceSyncGroupTests
Bug: 272189296
Change-Id: I921d78e347ecfb9786ebe4643308b347c5436332
This method returns if the callback is an OnBackAnimationCallback.
This value can be serialized and can be used to determine whether or not to run predictive animations when you have no way to check the callback directly, for example in the BackAnimationController you only have access to the IOnBackInvokedCallback.
Why?
OnBackAnimationCallback is used by apps that want to play a custom animation when the user swipes back.
OnBackAnimationCallback exposes BackEvent every time there is a new progress value.
Ideally, we would like to expose the velocity only on the last progress value (or onBackInvoked()), but to do that we have to change the API. We are unable to do so now.
Therefore, we decided to handle the fling gesture in the system instead. As a result, we now need to determine if the app supports OnBackAnimationCallback so that we only send the fling if we have an OnBackAnimationCallback registered.
BackAnimationController can now produce more back events. This is done by producing more events when the user lifts their finger. This way, the developer does not have to handle the fling gesture. This approach was chosen because the velocity cannot be exposed in the BackEvent.
Test: atest BackNavigationControllerTests
Bug: 263402927
Change-Id: I4d85253c9ade39f35ef0d8c70c6b1c7c31b1390d
If a caller adds a Transaction to a SSG after its already complete, make
sure to immediately apply the Transaction and log a warning. It's better
for the Transaction to get applied instead of waiting around forever.
Also cleaning up some logs in SSG
Test: SurfaceSyncGroupTests
Bug: 272189296
Change-Id: I6810c5e0c20f3fd5c7d8bde16f24bc05a0495b4f
The velocity of the `BackMotionEvent` will be used to fire additional events when the user lifts their finger.
Note: Velocity is calculated for the last event only, for performance reasons (see `VelocityTracker.computeCurrentVelocity`).
`Float.NaN` will indicate that the value has not been calculated.
Test: atest BackAnimationControllerTest
Bug: 263402927
Change-Id: I301636f572eb4e59abc69f6fee11d8dba5647a16
This allows apps like the Launcher to write ViewCapture data to the
wmtrace directory so it can be shown in their UI. Normally, Launcher
doesn't have the correct file permissions. Also, Launcher's dump method
is called after the wmtrace dir is written to the bug report, so we need
to dump sooner via a callback method invoked inside WindowManager.
Bug: 224595733
Test: Latency tested this change and verified that a bugreport generated
the file properly, moved it to the wmtrace directory, and was picked up
properly by the go/web-hv tool.
Change-Id: I9dc8e61070d2470354b79c1758103f9b2b00ac36
This passes a "debug" id along with transitioninfo
so that we can correspond transitions across processes.
Also adds debug-names to remotes so that they can
be identified across processes as well.
Bug: 276349701
Test: just added logs, so no tests needed.
Change-Id: If67524f8a82de366db2f96c8821b08eaec45ecb5
This will include a CHANGE info for tasks which have
moved to top while still visible. This allows recents to
be reported when a translucent task is running and also
provides a hook for multi-window order changes.
This also recalculates back-tasks on transient-launch finish
since, otherwise, the behind activity isn't paused. This
was because it wasn't changing visibility and just re-ordering
doesn't recalculate lifecycles.
Bug: 274696524
Test: TransitionTests#testMoveToTopWhileVisible
Start a translucent task, enter recents, then restore the task.
Change-Id: If21d076eed4db88139ffc8a7c4c018c2ef5aad93
This CL adds a new source SOURCE_ARBITRARY_RECTANGLE for the caller to
specify an arbitrary rectangle as the insets source frame in
InsetsFrameProvider. WindowContainerTransaction can use it to add and
remove insets with public insets types. This is a step to remove ITYPEs.
Bug: 234093736
Test: Presubmit
Change-Id: Ia9a851fe5bd0d09e4af9d170c839da5d0f8bf605
So far it is no problem so make it default behavior.
Bug: 151908239
Test: android.view.WindowMetricsTest
Change-Id: Ia56699786c57a95aff38e78f458b2dbe6793f22f
