| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds two WM transit types for opening and closing dream
activities, which allows the system to define transition in and out of
dreams, that are currently being overriden by other transitions.
Set the priority to be just below keyguard transit. The keyguard
occlude/unocclude already correctly handles the dream open/close
animation.
Bug: 222507937
Bug: 220311554
Test: atest WmTests:AppTransitionControllerTest
Test: manually on device by entering and exiting dreams over keyguard,
launcher, and settings. observed animation and relevant types of WM logs.
Change-Id: Iedfa279d56cd9d4c4679cb3b697ee74a98ef727b
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a trigger to DisplayContent that creates
unfold transition before applying the display size
and marks it as ready when the sizes are applied.
Adds a placeholder animation for fullscreen tasks.
Bug: 204925795
Test: enable shell transitions, open an app, unfold =>
check that app surface is animated
Change-Id: Ia88178a7c7849a99c17b4d18117a05b2a0fb8b7f
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
A direct display rotation goes through requestStartTransition
instead of "remote rotation". As a result, we need to hook-up
the handleRequest to shell's displayChangeController so that
other shell components (like task organizers) have a chance
to calculate new bounds for their organized windows.
Bug: 206872147
Test: via logging, ensure that shell DisplayChangingListener
is fired during a display rotation.
Change-Id: I839ebd28d4947ed3ec41d48724702d035f726f11
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation for attaching some extra meta information
to remote transitions (eg. process token). Most of this refactor
just replaces references to the raw interface with references
to the wrapper class.
There is also a small refactor in RemoteTransitionHandler to
better-manage death-recipients. It is possible to have >1 filter
and >1 pendings referencing the same remote simultaneously, so
this arrangement properly handles the 1-to-many possibility.
Bug: 183993977
Test: refactor, so existing tests pass
Change-Id: Icae8f2128e0ffdf7aee51284cba106963450e3e7
|
|
|
This adds IRemoteTransition interface for other processes (like
launcher) to register for playing transition animations.
Then there are 2 supported ways to "register":
1. Is to attach an IRemoteTransition to ActivityOptions. To
support this pathway, requestStartTransition now takes a
TransitionRequest object which can contain whatever info
is needed at the time. One piece of that is the passed-in
IRemoteTransition.
2. Is to register directly with shell (via systemuiproxy for
now) with a TransitionFilter. This filter allows shell
transitions to dispatch a transition to a remote without
need to make queries over binder.
This also hooks up launcher animations by converting the new
transition info to the old RemoteAnimationTargetCompat stuff.
Bug: 169035082
Test: launch app from launcher and observe the icon animation.
atest ShellTransitionTests
Change-Id: I8014a6f46cffda3a48a1a4ae101e2643078f4a14
|
