2bc5bd5168
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
WM Shell Test
This contains all tests written for WM (WindowManager) Shell and it's currently divided into 3 categories
- unittest, tests against individual functions, usually @SmallTest and do not require UI automation nor real device to run
- integration, this maybe a mix of functional and integration tests. Contains tests verify the WM Shell as a whole, like talking to WM core. This usually involves mocking the window manager service or even talking to the real one. Due to this nature, test cases in this package is normally annotated as @LargeTest and runs with UI automation on real device
- flicker, similar to functional tests with its sole focus on flickerness. See WM Shell Flicker Test Package for more details