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
- 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
This seems to be the overlay with the settings/close/maximize buttons
(please correct me if I'm wrong). With go/untrusted-touches the overlay
is blocking touches, since that's generated and owned by SystemUI with
original intention of letting touches pass-through to the
"pip_input_consumer" below (owned by the system), the fix is to make it
trusted.
Bug: 172629907
Bug: 158002302
Test: Put app in PiP state (eg. Maps), click on it and verify no
toast/logcat is shown regarding untrusted touch.
Change-Id: I4227d129b1d43ebc46cd169be7cae7f4e7ed9b9a
In an ideal case, onActivityPinned should always be followed by
an onActivityUpinned call in a PiP session. However, there are
possible times where it doesn't happen; PIP can crash suddenly,
or some other calls force closes PiP without it
getting a chance to call on Unpinned. In that case, menu isn't properly
cleaned up, so let's just make sure it is before trying to re-attach.
At the same time, move the call to onTaskAppear/Vanish, which is
guaranteed to be called.
Bug: 172268911
Bug: 172258041
Bug: 170315895
Test: Manual; Pause PiP, unpause PiP, menu still showing
Test: Locally hack so that detach doesn't get called the first time
(simulate crash), start PiP again - doesn't crash
Change-Id: I76984de59515f4178561ba92ae692fcc3c5edcb9
If the PiP is stashed and something causes it to move (such as, screen
rotation or unexpand animations after timeout), we calculate its current
snap fraction, get the new bounds and movement bounds, and re-apply the
snap fraction. However during the snap fraction calculation, it assumes
that PiP bounds is within the movement bounds, which is not true when
PiP is stashed. So take this into consideration when doing the math.
This also changes the stashed status to reflect more than just yes/no -
but rather NONE/LEFT/RIGHT.
Bug: 165793553
Test: Stash PIP while menu is showing, and wait for timeout
Test: Stash PIP, rotate the device, see that snap fraction is persisted
Change-Id: Ib4eda44b7f280362b52609e4092dd4231ac8f04c
Move first test out of android.systemui.cts.tv.PipNotificationTests to
com.android.wm.shell.flicker.pip.tv.TvPipNotification tests.
Bug: 171520419
Test: atest WMShellFlickerTests:TvPipNotificationTests
Change-Id: I6a3e2fb96a7688814ce909f28d6d904356fad3fd
Move common constants to a separate class.
Rename abstract FlickerAppHelper to BaseAppHelper.
Give BaseAppHelper a UiDevice (from androidx).
Make BaseAppHelper resposiblt for creating launcher.
Teach BaseAppHelper to launch app via intent and force-stop it.
Teach PipAppHelper to properly close Pip on TVs and work around
hasPipWindow() method not working on tv.
Bug: 171520419
Test: atest WMShellFlickerTests
Change-Id: Icc102a51351605b4adb27c3a1c2d73030eac33ff
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
Moves mTemporaryBounds and mAnimatingToBounds into
a new state class for animations.
Bug: 169373982
Test: com.android.wm.shell.pip
Test: drag, move, resize, fling, dismiss working fine
Change-Id: Ie487f0cad2a1b2c2e5efc4d0404c8812b2f6c8ff
Check if mPipMenuAcitivityController is not null before referencing.
Bug: 172227207
Test: manually on adt3
Change-Id: I2ba19d8c1795704057ff640764dc8133606e61f1
- 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
Deprecates also the SystemWindow reference in PipTaskOrganizer
Bug: 172274913
Bug: 172275014
Test: manually enter PiP with auto-pip enabled
Change-Id: I0c817a51fd3c24036151deec0cf1487759573d44
User can still move the PiP around, but disable:
- showing menu
- resizing
- double-tap gestures
Bug: 165793553
Test: Stash PIP
Change-Id: I899d8aa3ffffc4087c706f121dee69f63addc9ab
This is the first step to move the menu to fullscreen, but not quite
yet.
This CL does:
- Move PipMenuView to be attached to SystemWindow, instead of child of
PiP leash
- Use SyncRtSurfaceTransactionApplier to ensure the menu moves along the
PIP leash at the same time when the menu is visible
- Remove setup/destroy code in PipTaskOrganizer with SurfaceViewHost
- Expose Window information to Accessibility services
- Refactor ShellRoot to take in a Layer type instead of windowType
instead
Bug: 161710689
Bug: 170151121
Bug: 169894316
Bug: 152738416
Test: Manual
Change-Id: I73c26f96784b35b9bb9a4bea452df55cf5913278
