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
If the splashscreen uses an animated icon, we need to display it in a
surface view to avoid any jank if the view is passed to the client.
Test: CtsWindowManagerDeviceTestCases:SplashscreenTests#testHandleExitIconAnimatingActivity
Bug: 181757194
Change-Id: I7e2745a68626849374f5ebb9011c2e8c3b3b92c3
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
The splashscreenview can be replaced if starting window was transferred
and the first starting window didn't added success.
There should verify the appToken before setViewSynchronized set the
splashscreenview back to the container.
Issue sequence:
- Start first activity A, core request to add a starting window for it.
- Start second activity B, core try to transfer starting window from A
to B but since the window haven't added back, there will trigger to
add a new starting window for B.
- SystemUI add starting window to A but added fail because there was
transferred.
- SystemUI add starting window to B, success.
- Choreographer post setViewSynchronized to add view for A and B to the
container, because we only verify by taskId, so the SplashscreenView was
overwrite by A.
- After reveal animation finish, SplashScreenView#post will not be
executed because this view was not on screen.
Fixes: 188540606
Test: atest StartingSurfaceDrawerTests
Test: Open twitter from notification.
Change-Id: I894da75827556d3c1bc8bb0656196102de5a6847
Bug: 173562716
Test: visual - force user education to show & observe it on the
stack and manage menu
Change-Id: I6988e2c433f17b69de4aed44c1af3bacb475caf9
