Normally the bubble window isn't focusable so when the overflow
is opened/closed the window flags get adjusted so that the overflow
can get focus & key events.
Test: manual - expand the overflow and hit back button / gesture back
Bug: 185131171
Change-Id: I00f0063b3c7dd54327152d886bd74a8d1eec4231
* 16dp on either side / from edge of screen for the bubble view
* 16dp between bubble row & expanded bubble rect (works out to 5dp
in code: 16dp - 2dp (badge overhang) - 9dp (pointer height)
* max 8dp between the bubbles in the top row
* manage button has some adjustments - 8dp above & below and is total
32dp from edge of screen; ensure manage button is centered between
bottom inset & bottom of expanded view
* fixes a bug where there was extra padding being at top of expanded
view in landscape mode
* removed an unused layout file & unused dimens
Test: visual - expand a bubble, look at spacing of everything on
screen; do the same in landscape from left and right
edges of the screen.
Bug: 187715439
Bug: 183658029
Change-Id: I29e699aaf9b6e7bf75447dac6aa6b00a7b272b8b
Test: manual - add more than 2 bubbles, note you only see the top 2
- expand & collapse the stack, note you only see top 2
after collapse
- fling the stack around, note once it hits the edge
you only see top 2 bubbles but while dragging around
you see all of them following
Bug: 180142824
Change-Id: I168a14e1fba1506f53ed0734b55b44971d128de4
Bug: 160284881
Test: visual - have a bubble, expand / collapse it, update display
size, expand the bubble & check that the sizes have increased
& look correct
Change-Id: If6db9ae1b720f7f37fab31cbb6a67a48bee2e0f8
Instead of resizing to bounds larger than the default size
when the menu is shown, resize to the normal/default bounds
instead.
Also, remove the unused animateToMinimizedState() method.
Bug: 184789365
Test: enter PIP, pinch resize to min size, tap to poke menu -
verify that PIP expands to the default size
Change-Id: Ib0d7780fce2ec9157fb0f533d67b175ce699f40b
The generic rule to showing an empty splash screen is that if an
activity is launched from another visible activity besides Launcher.
So with this rule, when prepare the starting window for a launching
activity, we can tracking where the source activity comes from and
whether it has show splash screen or has drawn window before.
This can solve the inconsistent launch sequence when launching an
activity from non-system surface for the status either new task or
new process.
There will show an empty style splash screen if the launching
activity was drawn or it has show splash screen before.
Another coner case is that a process could start a new activity from
service, for the better UX we should also check whether there any
existing activities which were from the same process or same package
and has already at foreground.
We can still add "show icon_style_splash_screen" flag in the future.
Bug: 185433040
Bug: 185567723
Bug: 185448781
Test: atest SplashscreenTests ActivityRecordTests
Test: manual test
Launch browser from -1, empty splash screen
Launch calendar from launcher, icon splash screen
Launch work app from Settings -> Notifications -> Calendar show empty
splash screen
Launch Settings -> System update show empty splash screen
Launch Dialer -> call out -> show empty splash screen on InCallActivity
Change-Id: Id84f1f69de6c5e3f1c21cd249c62404958410193
The flicker test suite grew and now trigger a treehuger SLO violation. To address this problem create different groups for different tests using: --module-arg <TEST SUITE>:include-annotation:<GROUP>
Where:
<TEST SUITE> = FlickerTests or WMShellFlickerTests
<GROUP> = com.android.server.wm.flicker.annotation.Group1 or com.android.server.wm.flicker.annotation.Group2 or com.android.server.wm.flicker.annotation.Group3
For example:
1) to run only tests in the first group in flicker use: `--module-arg FlickerTests:include-annotation:com.android.server.wm.flicker.annotation.Group1`
2) to run only the third group of tests from wmshell flicker: ``--module-arg FlickerTests:include-annotation:com.android.server.wm.flicker.annotation.Group3`
Bug: 180620475
Test: atest FlickerTests WMShellFlickerTests with the respective parameters
Change-Id: I82f668713ba262bafe2758e2c618bfc060cc2c8a
* Allow bounds to be set on launch params for multiwindow activities
* Users of TaskView should pass bounds when starting an activity
otherwise they will see this animation
* Modify bubbles & controls to pass launch bounds
Test: atest TaskLaunchParamsModifierTests LaunchParamsControllerTests
MultiWindowTests
Bug: 182299605
Bug: 182516248
Change-Id: Ie5337593d776309f8aac0c6991cf846463e519a7
Fixes an issue where a max-size PIP is resized to the
user-resized size after either:
A) single-tap to show the menu and then it times out to hide
it, or
B) single-tap to show the menu and then single tap outside of
the PIP window
This was caused by the resize=true flag being passed into
PipMenuView.hideMenu() from the hide menu timeout runnable or
from PipResizeGestureHandler.onDragCornerResize()
Bug: 186616706
Test: enter PIP, then:
1) double-tap to MAX, then tap once to show menu and wait for
it to time out - verify it stays in MAX size
2) double-tap to MAX, then tap once to show menu and once
outside of PIP - verify it stays in MAX size
3) pinch-resize to minimum size, tap once, wait for it to
expand a bit, wait for the menu timeout - verify it resizes
down to the minimum size.
Change-Id: I394d49b77f2c6aa42fc4681ef5238c478a474b85
Tasksnapshot window can block touch event so user may not able
to touch the screen after showing task snapshot. Remove the delay
so app window can response touch event as soon as possible.
Bug: 187227846
Test: atest TaskSnapshotWindowTest
Change-Id: I5fb0fa3a1e6a5e6210d3baf400a84c5892bd2e34
Bug: 173562716
Test: visual - force user education to show & observe it on the
stack and manage menu
Change-Id: I6988e2c433f17b69de4aed44c1af3bacb475caf9
When a Task is detached but is still stored as a recent Task, it should
be allowed to launched into split screen.
Bug: 176061101
Test: atest WMShellFlickerTests:EnterSplitScreenFromDetachedRecentTask
Test: atest WmTests:RecentTasksTest
Change-Id: Ic72901ca76f4acb6e68926062675ecc290b399be
This handles the case were exitPip is called while there is a
animateResize PIP ongoing, such the menu expand/unexpand animation.
When that was the case, the first finishResize was applied at the same
time as the exit WCT, resulting in bad frames at the end of the exit
animation.
This CL makes it so that the first finishResize is skipped if we
know exitPip is handling the exit and will eventually call its
own finishResize operation.
Bug: 185306679
Test: enter PIP with YT, tap on menu to show it and immediately
tap on the app launcher icon to expand PIP - verify the exit
transtion runs smoothly
Change-Id: Iac49f69cc698f1ac5d88fd408c204e2281b70ac7
Restrict the PIP resize to the left and right edges only,
instead of allowing the top or bottom edges as snap targets.
Bug: 186610221
Test: pinch to resize and let go at the center top or bottom
edge - verify it snaps to either side of the screen
Change-Id: Ifbc96fddc000ccb2ae344755a9276f24e67d4571
Also fixes a bug where the overflow view would still leave space
for the manage button even though we don't show something there.
Bug: 183658858
Test: manual - open a bubble and observe the manage button, should
be on a dark background with light text regardless
of light / dark theme.
Change-Id: Ie3f67ccd26ad4d75a3ed21a3dee43e2f74d07022
