Shell Transitions operates on the leashes both before and
after the animation in order to adapt shell transit to the
legacy transit impls in launcher.
This means we can't release the surfaces before the finish
callback. Since the finish callback provides a convenient place
to release the surfaces anyways, we can effectively disable
the release here.
Bug: 186158221
Test: enable shell transit, physically rotate to landscape,
launch messages and then close it (back-gesture) repeatedly
and observe that launcher doesn't crash.
Change-Id: Ibdc958b1fd18d66a013d94b70772ce49409fb4c1
When autoEnterPip from Task with multiple activities, besides passing
the mLastRecentsAnimationBounds we should also try to pass the last
PictureInPictureSurfaceTransaction to the new Task and apply both.
Changed also
- deprecate the last recents animation bounds and use the transaction only
- reset the transform once applied to the original task
Known issue: original task appears transparent in overview once.
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/hNZ0H62PqgVDEUGh1TVMiT
Bug: 184789412
Bug: 185509920
Test: manual with ApiDemos, see Video
Change-Id: I7fb77e41e1963e14ecaf53bd135d6b4cb24493c9
This adds a couple things to support "merging" of transition
animations in shell.
1. Moves the finishing surface operations into a transaction that
gets sent to shell. This does a couple things: it complies with
the contract we have where during a transition, only the player
should touch relevant surfaces; and, it makes it so that the
player can merge the transaction with other ones.
2. Keeps a queue of "pending" transition animations in shell and
either merges them or runs them serially.
3. Any transition that becomes ready while another is playing will
first be sent to the playing handler to give it a chance to
"merge" the incoming transition.
There are 3 expected responses to overlapping transition animations:
1. Cancel the currently playing transition and immediately start
the incoming one. This can be achieved by having the currently
playing transition cancel itself (ie. immediately finishing) when
a merge request comes in. Then the rest of the shell transition
logic will immediately start the next transition.
2. Queue up the incoming transition to play once the current one
finishes animating. This is basically the default as long as
the current transition simply rejects/ignores merge requests
3. Merge the incoming transition. This is achieved when the
currently playing transition actually does some special logic
to handle the incoming transition. It then calls the finish
callback for the incoming transition (before it finishes its
own animation) to indicate that it has been merged (or "consumed").
Basically, any time the finish callback for a transition is
called before a pre-ceding transition, that transition is assumed
to have been merged.
Bug: 183994113
Test: atest ShellTransitionTests
Change-Id: I3cb54e221d57642306ddf15827c21d8881b014d0
- Move new matrix/rect construction to if the param is set on the
builder, we only apply the params if the flags are set anyways
and if the caller doesn't set those params then we are allocating
new objects unnecessarily
- Always recycle motion event
Bug: 183756396
Test: Take memory profile when dragging pip
Change-Id: Ie7457c8c508ee61bd27daeebe486c39a5cebe7d7
InputMonitorCompat is only instantiated directly now, so we can remove
old code for passing it from SysUi through Parcelable.
Test: compiles and runs locally
Bug: 185266621
Change-Id: I54e394c1eb9c702beeb5bbfbae7a140c29530c33
We are enabling a new lint check where the min sdk != compile sdk.
It has produced a lot of errors and adding the baseline file(s)
allows us to continue work without introducing more problems.
Bug: 150847901
Test: m lint-check
Change-Id: Ide8a8fe80ba31396f23853ab266afcbcc33af9a6
This makes StageCoordinator implement the TransitionHandler
interface.
In general, this currently expects 'enter' transitions to
contain 2 tasks (one in each split). The current UX is undefined
when one only one of the splits is occupied, so for now it will
throw an exception if that case is hit.
There is a split-screen API called startTasks which takes a list
of tasks (currently only supports 2) and associated options and
creates a transition to both enter split-screen and launch those
tasks into their respective stages.
These are the currently accounted-for entrypoints into
the handler interface:
- Core-initiated (handleRequest)
- in split: trigger=HOME that is opening -> full dismiss.
- in split: trigger=task with a stage parent that is last closing in
that stage -> dismiss with other stage onTop
- NOT split: trigger=task with stage parent -> exception
- Shell-initiated
- NOT split: startTasks -> enter split with 2 tasks
- in split: snap-to-dismiss -> dismiss with other stage on top
Bug: 182002789
Test: atest SplitTransitionTests
Or use the experimental pair-launch split-screen and observe
protologs to see clean transition-infos.
Change-Id: I4f4dd431ad5642cf98b4a01c32eb1d09e5b9a11e
- Allows launcher to get the associated launch cookies for
the task
Bug: 129067201
Test: Manual, check the task info for the animation targets
Change-Id: I4b9d974af1732d0ec7b19681f4772b692f614e5e
Take the full transaction details passed from Launcher, including
position / windowCrop / scale / roundRadius and apply them in
RecentsAnimationController.TaskAnimationAdapter#onCleanup to make sure
the final state of autoEnterPip transition can be carried over.
Note: there are still several frames off when entering PiP from
landscape with autoEnterPip being enabled.
Bug: 179720719
Test: manually using the ApiDemos app
Change-Id: Ibfff75e09943960cfcd816d6c52a80d7a8af8fe8
This is the shell-transitions equivalent to RemoteAnimationRunner.
The OneShot handler is a utility to directly tie one call of a
remote transition to a specific transition (via
Transitions.startTransition) or as a general holder of a remote
for shell to use (taking care of binder lifetime and wrapping
callbacks).
Bug: 182002789
Test: ShellTransitionTests#testOneShotRemoteHandler
Change-Id: Ia405b133b18b4f132c8c841e74a6a264561df5a3
- Expose interfaces for splitscreen, one handed, shell transitions,
starting window
- Make the shell code only reference the starting window controller and
not the exported interface
Bug: 180074017
Test: atest WMShellUnitTests
Test: Verify Pip calls from Launcher work
Change-Id: Idafed90a8ed3382adfb4322b4b1797237be86a90
- Also split impl and controller for ShellInit/ShellCommandHandler
(as with ag/13502602)
- Example implementation of exposing a subset of the Pip interface to
Launcher directly. This has the benefit of reducing unnecessary code
in SysUI just to pipe calls to the Shell.
The controller implements the binder interface which is collected
and exposed to Launcher when it binds to the overview service
and Launcher can call through the binders directly.
Note: this requires the shared lib to also build with the Shell
interfaces so changes to the Shell aidls will still require updating
the shared lib (until the shared lib prebuilt can removed).
Bug: 180074017
Test: atest WMShellUnitTests
Test: Verify Pip calls from Launcher work
Change-Id: Id74114da6a6a73d32c957f84fce5bbe23e87ba01
This puts display-content as another WC in a transition. It then
adds WC rotation to change tracking. If there is a rotation,
the shell-side handlers will play the transition.
This replaces ScreenTransitionAnimation, seamless-rotation, and
fixed-rotation:
ScreenTransitionAnimation implementation will move to shell.
seamless-rotation is redundant because the rotation setup is
intrinsically "seamless": it requires shell to imbue an
animation onto it rather than just doing the jump-cut.
fixed-rotation is now just a custom animation where we
counter-rotate the closing app on frame 1 and then perform
the normal open animation on the opening app.
Bug: 179270750
Test: DisplayContentTests#testShellTransitRotation
enable shell transitions and rotate the device or launch
and close apps in different orientations.
Change-Id: I4bc23b2e614ba85bf9752f62da4c3f8d0c90436d
At the end of autoEnterPip transition, followings happen in sequence
- Transition finishes in Launcher side, which operates on the
animation leash
- RecentsAnimationController.TaskAnimationAdapter#onCleanup has the final
chance to set the Task leash
- PipTaskOrganizer gets onTaskAppeared callback and commits Task into
pinned mode
What's been changed here
- Transition in Launcher no longer in charge of settle the final transaction
- RecentsAnimationController.TaskAnimationAdapter#onCleanup sets the
Task leash to be in sync with the final state in Launcher side
- PipTaskOrganizer commits the final leash transaction together with
WindowContainerTransaction that enters PiP
Known issue: transition from landscape is not polished
Video: http://rcll/aaaaaabFQoRHlzixHdtY/hT5SXvaCy28P4UtfuoKiDw
Bug: 181342797
Test: see video
Change-Id: Ieabd6991ea5174099714ec22970198bebde1e336
- Expose interfaces for splitscreen, one handed, shell transitions,
starting window
- Make the shell code only reference the starting window controller and
not the exported interface
Bug: 180074017
Test: atest WMShellUnitTests
Test: Verify Pip calls from Launcher work
Change-Id: I49a5a0419996754e5e154df7af1e475268035a5a
- Also split impl and controller for ShellInit/ShellCommandHandler
(as with ag/13502602)
- Example implementation of exposing a subset of the Pip interface to
Launcher directly. This has the benefit of reducing unnecessary code
in SysUI just to pipe calls to the Shell.
The controller implements the binder interface which is collected
and exposed to Launcher when it binds to the overview service
and Launcher can call through the binders directly.
Note: this requires the shared lib to also build with the Shell
interfaces so changes to the Shell aidls will still require updating
the shared lib (until the shared lib prebuilt can removed).
Bug: 180074017
Test: atest WMShellUnitTests
Test: Verify Pip calls from Launcher work
Change-Id: If048d2cd9a6b8e5014ba30c0deaed7a3e177605d
Signed-off-by: Winson Chung <winsonc@google.com>
- Create a new method in StatusBar to enable/disable nav bar luma
sampling.
- Modify the IRcentsAnimationController.detachNavigationBarFromApp() API
to notify the server side whether we should run the fade-in animation
or not.
- Don't let fixed rotation animation control the navigation when it's
controlled by recents animation and vice versa.
- Don't attach nav bar when it's in split screen mode and in landscape.
- Translate the nav bar surface to match the secondary app's bounds in
split screen mode in portrait.
Bug: 139273001
Test: atest RecentsAnimationControllerTest CommandQueueTest
Change-Id: I06dc2dd0655bc8a2e6ad03808576e55294a322e8
When StartingWindowController receive addStartingWindow, send a callback
out so a listener can know whether current launch cold or warm.
Ref doc: go/starting_window_android_s
Bug: 131311659
Bug: 131727939
Bug: 152480470
Test: atest WindowOrganizerTests StartingSurfaceDrawerTests
SplashscreenTests
Change-Id: Ic9f02f51d5de141b56a8f28003bf1cb1a5a63f22
1. Only send navigation bar target when:
- The transitition is app launch
- In gesture navigation bar mode
- The navigation bar is not controlled by fixed rotation or recents
2. Add a windowType field to RemoteAnimationTarget so that the remote
clients could use this to find the non-app window they want.
Bug: 139273001
Test: atest RemoteAnimationControllerTest
Change-Id: I7003011351913b040b47e6fb567eedb4baf34a55
Makes the following changes:
1. Adds a boolean visible parameter to the onTaskChanged method of
SplitScreenListener to allow the launcher to determine which task is
on top of a stage
2. Allows the launcher to specify a fill-in intent when asking to open
a PendingIntent on the main or side stages.
3. Allows the launcher to ask to remove a task from the side stage.
Bug: 179176511
Test: manually tested against the foldable taskbar launcher.
Change-Id: I9fa530f546af58779ccf71d0753d9b6d3479fd0b
This is mostly to clean-up CL diffs so its easier to tell
what is changing. The main change here is replacing naked
parint == null checks with TransitionInfo.isIndependent() which
can do extra logic to handle cases where, even though a change
has a parent, it might be animating independently with in it.
The easiest example is display rotating while an app is opening.
This also fixes a small bug when removing a non-visible task.
Bug: 179270750
Test: atest TransitionTests
Change-Id: Ibd72b0721f33602b26bcc5c7060fc959aed04377
