- 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
Only call assumeTrue(isTelevision) during test setup (@Before), and do
not call it in teardown (@After), which causes tests to fail instead of
be slipped.
Bug: 171520419
Test: atest WMShellFlickerTests
Change-Id: I12f72d46a63c497686f0da7c4763ae79bbeb7dcd
Test: have a bubble, open it, focus IME, remove bubble, open anything else
and check that the IME still works.
Fixes: 172977221
Change-Id: I73d57d81d274f5af0e8f69e158f3ccb862e0d379
Currently you can only access the overflow if you have bubbles in
the stack. There are a bunch of explorations that show accessing
the overflow without the stack (e.g. from taskbar, from people area).
- BubbleData holds onto BubbleOverflow now
- When last bubble is removed, if showing in taskbar/already expanded
& has overflow bubbs, select the overflow.
- No longer null out BubbleStackView when no more bubbles, this
allows overflow to continue to show
- Added tests for overflow behaviour in BubblesTest
Test: atest SystemUITests
Test: manua 1) - produce a bunch of bubbles
- expand the stack, dismiss each bubble
=> when you dismiss the last one, overflow selected
- collapse the stack
=> overflow goes away
2) - have taskbar cl / prototype
- have bubbles in the overflow but no active bubbles
=> observe that taskbar shows the overflow (i.e. sysui
renders the stack in that spot)
Bug: 171322463
Bug: 167413172
Change-Id: I36b9cedc492ace59105dba58c89f9ef92ff4b9e8
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
Now that all state handling has been moved out of
PipBoundsHandler, this CL renames it to
PipBoundsAlgorithm and cleans up its public API
so that it functions more like an utility to
calculate several types of "bounds" related to PIP
such as:
- Default bounds
- Normal bounds
- Movemement bounds
- Entry bounds
- Bounds adjusted to aspect ratio
- Inset bounds
PipBoundsAlgorithm's is then only responsible for
calculating such bounds based on the current state of
PIP (owned by PipBoundsState) but it no longer owns
or manages the state, as that would be the
responsability of its users (e.g PipController).
Bug: 169373982
Test: atest com.android.wm.shell.pip
Change-Id: I67c3004b60069160f82d7c3d00d8c3995c0c5f80
- Added a new DisplayArea feature for hide display cutout
- Added a new config for enable/disable hide display cutout
- Resize and shift display areas to exclude the cutout areas.
- Force dark status bar when there is a cutout area at top
- Update bounds & offsets for different rotations.
Bug: 157388722
Test: atest HideDisplayCutoutControllerTest
atest HideDisplayCutoutOrganizerTest
atest WMShellTest
Change-Id: Iad2c8b1eff1ea4523f8a7e362c9e851d8594141c
- The drag count needs to be per-display since using a global count
would prevent us from hiding the window for the non-last display
Bug: 169894807
Test: Drag and drop with a foldable device and ensure that no drag
window lingers for a secondary display
Change-Id: I5bb26d07c143ab4f062deb34f1564735a095817f
Also only allow stashing if user starts dragging from that edge.
Bug: 165793553
Test: Stash PIP via flinging
Change-Id: Icfd6d8d580cfb96b148f7712d0aedfcee1f30b2d
getDestinationBounds(Rect) was only being used to calculate
the "entry" bounds (e.g. onTaskAppeared, swipeToHome) and
all its callers were passing in null.
getDestinationBounds(Rect, boolean) had only one caller,
onTaskInfoChanged, who did pass the current bounds in to
be adjusted to the aspect ratio.
Instead of having overloaded methods and complex logic to
know whether to calculate default bounds or use the provided
bounds, the method is now split into two methods that better
represent what they're calculating:
1. getEntryDestinationBounds, no arguments, calculates either
default or reentry bounds
2. getAdjustedDestinationBounds, takes in the current bounds
and the new aspect ratio, simply adjusts the bounds to the
aspect ratio.
Bug: 169373982
Test: atest com.android.wm.shell.pip
Change-Id: Ie8adda458fc5a56b9d78245c663dbc54b8525378
Mirror PhoneWindowManager#addSplashScreen to StartingSurfaceDrawer,
which make WMShell able to draw the splash screen starting window.
- Use StartingSurfaceController#DEBUG_ENABLE_SHELL_DRAWER to switch
drawer when developing this feature.
- Temporarily put StartingSurfaceDrawer in ShellTaskOrganizer, the
drawer should be controlled by a controller which should be create
while porting ActivityRecord#addStartingWindow to Shell.
Ref doc: go/delegate_starting_window
Bug: 131727939
Test: atest AppWindowTokenTests WindowOrganizerTests ActivityStackTests
Test: atest WMShellTest ShellTaskOrganizerTests
StartingSurfaceDrawerTests
Test: check from winscope that the splash screen window can
attach to/detach from the ActivityRecord.
Change-Id: I6dfc9ff75807e2f9479149d14f219c91a6527393
- Ensure that the task info activity type always matches the actual task
activity type (can be different than the window configuration type)
- Ensure that the targets hit rects respect the insets, and that dragging
out of all targets (but still within the window) will hide the last
target
- Work around race with launching secondary task when splitting, wait
until the split screen task org has moved existing tasks to secondary
split root before starting the new task, and also update the home task
position when going home (b/172686383)
- Add a timeout to clean up drag surfaces if SysUI crashes while
mid-drag
- Clean up some other calls to get activity type/win mode
Bug: 169894807
Test: atest DragDropControllerTests
Test: atest DragAndDropPolicyTest
Test: atest SplitScreenTests
Change-Id: I7ae11cc38b1e927d955798ef1056e17c9e435758
- Have shell provided a task stack listener that various controllers can
add to, and remove registration from outside the controllers (this
also removes methods on the interface exposed only for use from the
task stack listeners)
- Move copy of InputConsumerController into shell (shared lib version
can probably be refactored into use just by launcher for gesture nav)
- Hide remaining wm components that are exposed now that all the
features are in the Shell
Bug: 169894807
Test: atest WMShellUnitTests WMShellTest
Test: Verify Pip/Split/One handed still behaves as expected
Change-Id: If0f50f6b701ac4b013a9e41fe6f88857ea35bf5b
Fixes an issue where activities using the manifest min
width/height was causing them to not be resizable.
This was caused by:
1. transformBoundsToMinimalSize is called on drag resize, which
causes the bounds to go back to the minimal size.
2. After fixing 1, drag resizes "jumps" from the minimal size to
the default bounds because the normal bounds are not set to the
minimal size
3. Reentry bounds are not restored correctly because when
calculating the destination bounds, the bounds where always
transformed to the minimal size at the end.
This CL changes a few things to fix these issues:
1. The minimal size is now considered when calculating the
entry bounds or transforming bounds to aspect ratio. This means
that instead of calculating the bounds/size using the "default"
size and then adjusting to the minimal size, we'll look at
whether we should calculate using the default or the minimal size
from the very beginning.
2. When the minimal size changes (onTaskAppeared, onTaskInfoChange,
swipeToHome), the normal bounds and movement bounds need to be
recalculated. The normal bounds are the default bounds, and the
default size changes if the minimal size is set or unset.
3. The min edge size used to be set by PipTouchHandler depending
on whether PIP is expanded to either expandedMinEdgeSize or 0. It
is now set to mDefaultMinEdgeSize if not expanded. This was not
causing issues before but it started to with these changes.
Also moved the minEdgeSize and overrideMinSize to PipBoundsState
as part of b/169373982
Fixes: 172598623
Bug: 169373982
Test: com.android.wm.shell.pip
Test: enter pip, expand, resize, reentry bounds,
minimal size in manifest, aspect ratio change all work
correctly.
Change-Id: I4baa46eb641323282fc23fd4499365c83ff38a7d
