Split-screen implementations moving forward would be based on app-pairs
and main/side stage models. So, renaming existing package to avoid
confusion.
Bug: 175416931
Test: They pass!
Change-Id: I55ab1d27fb1c00ba7a58d685ea7eb2840efb9437
This is the first step towards moving letterbox gravity logic from WM Shell to WM Core. It's important to do this even before the new implementation in WM Core is ready because surface repositioning in WM Shell causes visible flickering on rotation for all apps on devices with cutout.
Fix: 174632285
Bug: 175212232
Fix: 173440321
Test: atest WMShellUnitTests
Change-Id: I2b3706a1a46bb2c7ee4bb3789fb09b216e32f290
Update SplitLayout and DividerView to support dragging divider bar and
make them more generic to be able to share among different split impl.
Bug: 172704238
Test: manual check the behavior of divider bar
Test: atest WMShellUnitTests
Change-Id: I16ed1fd86bdff4d8544c5787c95315c59055ad04
Add divider bar for app-pairs. AppPairLayout and divide policy records
and handles the layout in pair.
Bug: 172704238
Bug: 172704672
Test: manul check the behavior of the splits and divider bar.
Test: AppPairTests, AppPairsPoolTests, AppPairsControllerTests
Change-Id: I688c7001d056fe8dd9a192885e1f9fd5f004dc11
- AppPairs: Main interface used to pair and unpair tasks.
- AppPairsController: Main controller for app-pairs and implements
AppPairs interface.
- AppPair: Manages a singal instance of an app-pair consisting of a
root task and 2 other tasks that are paired together.
- AppPairPool: Helper object pool for AppPair class so we don't have to
wait for a root task creation from system_server when we need an
app-pair.
- adb shell commands for pairing and unpairing tasks
Test: adb shell commands for pair/unpair
adb shell dumpsys activity service SystemUIService WMShell \
pair taskId1 taskId2
adb shell dumpsys activity service SystemUIService WMShell \
unpair taskId
Test: AppPairTests, AppPairsPoolTests, AppPairControllerTests
Bug: 172704672
Change-Id: Ie0a70c1aa764ad83b763931501234c1960251ca4
This will enable some stuff for taskbar & hopefully make customizations by
ARC++ easier??
- BubblePositioner now tracks the size of the bubble & bitmap within it.
Have to use a multiplier to derive the size of a couple of things now
(e.g. bitmap size)
- BubblePositioner now tracks the position of the bubble stack & allows
a way to override / set a fixed position. If something is in fixed
location, it is not draggable (however when expanded you can still
drag individual bubbles to dismiss)
- BubblePositioner tracks some taskbar related info
- Rather than checking for "isLandscape" we want "showBubblesVertically"
(e.g. device might not be landscape but should be vertical if taskbar)
- Fixes an animation issue where bubbles super-overshoot the y position
when expanding vertically.
Bug: 167413172
Test: a lot of manual testing
Test: atest WMShellTest SystemUITests
Change-Id: I79948a4bd6b58fb3aa2f52e2553f3dfc31630cf1
Move bubbles package and related resources to shell package,
also copied some used codes and resources.
Bug: 161980186
Test: atest SystemUITests
Test: atest WMShellUnitTests
Change-Id: Ia108bd4149b3c3bf86631ba1a7a6bce0e76af78f
- Add basic policy for handling drags over home/fullscreen tasks
/split tasks. For now, default to only allowing split to non-docked
root task
- Refactor drag layout to have same lifecycle as the window instead of
being per-drag session
- Resolve activity info for tasks as well as activity drag items
(shortcuts to be resolved in a follow up CL)
- Fix crash due to sending drag events to all displays
Bug: 169894807
Test: atest DragAndDropPolicyTest
Change-Id: I7d777c59296e9ca9e1d169c8a021f9263af94d65
Make .tv.PipController rely on PipMediaController for media session
monitoring and managering.
Refactor .tv.PipControlsViewController to use PipMediaController to
retrieve the media buttons.
Make .tv.PipNotification subscribe to PipMediaController to receive
callbacks about media metadata updates.
Bug: 169575409
Bug: 165795012
Test: make WindowManager-Shell; make SystemUI
Change-Id: I397f93eb4433116ba4f476bda7374b07d97e082d
- Add mechanism for creating PendingIntents to launch apps in the same
way as starting through LauncherApps service
- Require callers starting a task launch to either be the recents
component or have the START_TASKS_FROM_RECENTS permission
Bug: 169894807
Test: atest LauncherAppsTest
Test: atest DragDropControllerTest
Change-Id: I2f9f622b4ef7a8aba06b0854a1549a2c07cf38e1
Currently some of the information about a task created by createRootTask
is returned with the method and the rest like leash is return in
onTaskAppear. Mixing both async and sync infromation return styles
complicates the mental model for this. So, we will have this be
completely aync for now.
Also, fixed an issue where the windowing mode for organizer created
task was not set correctly before the organizer gets the first task
appear signal.
Bug: 169266958
Test: Split-screen works!
Change-Id: Ia4180d5a42838bf566fbf75f40466dfd8237e0f1
- Add private window flag INTERCEPT_GLOBAL_DRAG_AND_DROP (protected by
MANAGE_ACTIVITY_STACKS permission) to be considered as a part of the
normal flow for global drag and drops even if the window is not
visible. In addition, the window with the flag receives the clip
data on DRAG_STARTED and the drag surface on DROP. If the window
consumes the drop, then it will relinquish cleanup of the drag surface
from the system.
- Add MIMETYPE_APPLICATION_ACTIVITY for an app to report that they are
starting a global drag of an activity. The associated data must
include an intent with the pending intent and user to launch the
activity for.
- Add a test drag handler on the shell end to receive the drag, setup a
drag layout, and just launch the intent (for now).
Bug: 169894807
Test: atest DragDropControllerTest
Test: atest DragDropTest
Change-Id: I7f5cdca3cf515b693a8f1e507e90e22a670b5fa6
Merged-In: I7f5cdca3cf515b693a8f1e507e90e22a670b5fa6
Signed-off-by: Winson Chung <winsonc@google.com>
We return TaskAppearInfo on TaskOrganizer#createRootTask so it doesn't
have to wait for taskAppeared signal to take action.
Also, added createRootTask(..., listener) method to ShellTaskOrganizer
so that a specific listener can be associated with a root task we are
creating.
Bug: 169266958
Test: split-screen works.
Change-Id: I5948e623481deadb0aa5fc99b9941914f44a68e2
Allows for managing specific task regardless of windowing mode.
Converted TaskView which to use the new API.
Bug: 170153209
Test: All tests pass and bubbles works!
Change-Id: Ic5281bc9dd9124841834c88f2b85545107567417
- Existing tasks for supported windowing modes are returned when
registering the organizer and the organizer will not receive
onTaskAppeared() for these tasks. For now, the shell task
organizer will keep these tasks for reporting task appeared when
individual components add listeners for their windowing modes.
- Fixed some tests now that we organize fullscreen tasks
Bug: 162028888
Test: atest WindowOrganizerTests
Test: atest ShellTaskOrganizerTests
Change-Id: Iedc5f58fbfa819e753a5dcea7a8eb9dee8b6843b
Stop using windowing modes as keys for task listerners mapping to allow adding multiple listeners for one windowing mode.
Fix: 170209272
Test: go/wm-smoke
Change-Id: I31c20a00f8747a8510a5fab9e54efa63173aab6a
Initial rough implementation of Shell Transitions.
Shell Transitions can be enabled by setting ENABLE_SHELL_TRANSITIONS
via `adb shell setprop persist.debug.shell_transit 1`
The main structure behind this is:
- TransitionController in Core responsible for handling the
collection of transition participants and communicating with
the TransitionPlayer in Shell.
- Transitions in Shell responsible for starting transitions
and playing associated animations.
This initial version only supports task open/show/close and does
a simple fade. The flow is:
1. activityStarter calls to Transitions.requestStartTransition
2. Transitions will prepare to start and then call
WindowOrganizerController.startTransition().
2. Various operations in Core call TransitionController.collect()
to track participants. This collect() acts as a replacement for
adding to mOpening/ClosingApps.
3. The legacy executeAppTransition() is wired into
TransitionController.setReady() for now. This signal
is used to ready a BLASTSyncEngine.
4. When all participants are done drawing, TransitionController
will commit any showing visibility changes and then will construct
a TransitionInfo object summarizing all the changes needed for
animation. This gets sent to Transitions.onTransitionReady()
5. Transitions then plays the transition animation and on
completion will call WindowOrganizerController.finishTransition()
which will tell TransitionController to do any finishing
work (like commiting deferred hide changes).
Bug: 161980187
Test: enable the flag and try opening/closing tasks. Also added
TransitionControllerTests
Change-Id: I80c3a241fc12004a894c26523a1e5828e0c533ff
