This test is needed for testing overview-grid-related functionality.
- Opening non-focused tasks
- Dismissing a non-focused task from the grid
- Grid rows rebalancing after dismissal, which only happens when enough
apps are open to be off-screen.
- Grid tasks do not scroll after dismissal.
Test: TaplTestsQuickstep.java
Bug: 197630182
Change-Id: Ic907db4643cdc2eb9e4610dab917347e234e470c
Generalized popup menu types and logic to allow wider uses outside of launcher.
Bug: 198438631
Test: long pressed launcher icons and pressed menu options
Change-Id: Iadcbb1796496c0061dcee362784e426ff55dc94a
> Also keeping it stashed while all-set activity is visible
> Creating a shared state (simiar to saved instance state) for taskbar
> Keeping taskbar stashed while all-set activity is visible
Bug: 194786060
Bug: 201782272
Test: Manual
Change-Id: Iab5e082243a206772266aece62d3028f5acb6400
- Animate in onStateTransitionStart
- Commit in onStateTransitionComplete
Fixes: 193938970
Fixes: 200765631
Fixes: 201644899
Test: Go home from overview; Go to all apps from home; Go to overview from home
Change-Id: I393022c86f09806fea29fb5bc7191304b473f231
* Getting a callback from shell to inform when task is in split
and when it's been removed is asynchronous, and not
coordinated with launcher's swipe up gesture.
* There's a chance that user can quickswitch to single app
and start swipe up before shell could notify
LauncherSplitScreenListener, which would cause mismatched state.
Bug: 199658495
Change-Id: I722eeb26d83e99b2a2f77748984d0d7c390b5fec
- Align nav buttons (only back is enabled) to start instead of end
- Don't animate from init()
- Provide 0 contentInsets.bottom
- Auto-stash the taskbar during setup
- Hide the stashed handle by adding an alpha channel for home disabled
- Report 0 contentInsets when stashed if the handle isn't visible
- Tint nav buttons according to theme
Test: adb shell am start -a android.intent.action.MAIN -n com.google.android.setupwizard/.SetupWizardTestActivity
Bug: 194786060
Change-Id: I4a40501e8aad2a38ec00398efe9ea3dbfa7428cd
* Animate translationY alongside icons
* When device rotates on home, update
translationY
* Add padding to contextual buttons to center
it
Bug: 189807374
Change-Id: I149ef25df570fb1fd385f1da960c827105ff975d
- Added new layout files for mock screens.
- Added new mock hotseat
Bug: 198434693
Test: launched and completed tutorial on regular phone and foldable device.
Change-Id: I1ad04f9e8e3a012528d6fd8fbaa0366687c65d06
Fixes: 193375232
Test: Swipe up from app in landscape mode, interact with Overview, and make sure it's interactive
Change-Id: Ib1838f02d537918b7a13d51a1fdcacbf3d02b99d
- There is an edge case that when ClearAllButton is visible, no split translation is applied, the offset adjustment needs to be calculated differently in that case
- Also, apply the scrollOffset to the TaskViews / ClearAllButton instead of updating min/max scroll
Bug: 200537659
Test: Split right in grid, split left with clear all button, split left without clear all button
Change-Id: I869c448bbec6aec8fa070e47193a692be6f75e84
When bubbles are expanded a scrim is shown on top of
everything. Taskbar is layered above bubbles but we still
need the scrim to show on top of it. This CL adds the
ability to show a scrim on taskbar.
The scrim is a view in the taskbar drag layer and is
placed between the taskbar and the nav buttons so that
it can block touches / scrim the taskbar but still allow
the nav buttons to be visible and touchable.
Add interpolators for alpha matching what bubbles is using.
Test: manual 1 - expand bubbles while taskbar is visible
=> observe scrim
- open manage menu
=> observe darker scrim
2 - check that taps on scrim collapse manage
menu or stack
3 - check there isn't a scrim while taskbar is
stashed and bubbles / manage menu are open
4 - check that three button nav works while
bubbles are expanded
Bug: 197139718
Change-Id: I94c4ecd07f81b2bad55c38525d60f493d3c1f9d8
In 0 button mode, stashing morphs the icons into the home handle. In 3 button mode, that doesn't make sense, but we should still hide the icons (and just keep the 3 nav buttons). You still can't manually stash via long press in 3 button mode, but this will address other states where we automatically stash the taskbar when we want to hide the icons from users (e.g. when pinning an app).
Test: Pin an app from overview in 3 button mode, ensure the taskbar icons disappear until unpinning
Bug: 190192993
Change-Id: I499c59bd9d7871ff64696b67065cf9d4863222a5
Test: pin an app from overview, watch taskbar stash automatically until unpinning
Test: turn off suggestions for hotseat, remove all items and watch taskbar stash automatically when opening an app
Fixes: 190192993
Fixes: 193937948
Change-Id: Ia7260c60a820af1a48c9e4a400a52753baf34d41
This is to prepare for different flags that could cause taskbar to be stashed in an app without the user explicitly long pressing to stash.
Test: run wwdebug and wwlogcat, ensure still get logs for long press stash events; other interactions like clipping tasks to above unstashed taskbar still work as before
Bug: 190192993
Bug: 193937948
Change-Id: I90846e650a438e03bdcfdf9c4bf919e19cc5abb3
* Notify SystemUi to suspend autoHide behavior
until launcher notifies otherwise
* There's no exclusive lock for AutoHideController
behavior, so down the road another component can
choose to resume auto-hide behavior even if launcher
has requested otherwise (and vice versa),
something to keep in mind.
Fixes: 193938507
Test: Opened folder while in immersive video,
taskbar stayed open.
Change-Id: I12f4055911822893551683466cfd532c8108a3a0
* Animate it back into position after user unlocks
* Re-create taskbar on layout direction change so
PropertyHolders are recreated to take into account
new values
Fixes: 199852418
Test: Tested w/ password + pin for gesture + 3 button
Change-Id: Ie7f16f737a8fc12328c05d7628d0e3ae09fc08ca
- Portrait's split placeholder is at top/bottom and does not affect scroll
Bug: 200537659
Test: Split left and split right in portrait / landscape, check if min/max scroll is correct
Change-Id: Ib7eb09d3cc44c8e0d962920ad094c73abc5f0dbd
- Fix logic for canceling animation for continued quick switch, so that this case (starting a new gesture before onRecentsAnimationStart() of the previous gesture) instead goes to the STATE_FINISH_WITH_NO_END flow.
- Update the end target so that we go to that state instead of always overview state if swipe was past the halfway threshold when we call endLauncherTransitionController(). This is specifically so we don't use OverviewInputConsumer on the second gesture, given the first one was canceled and didn't actually go to overview.
- GestureState#isRecentsAnimationRunning() now checks for STATE_RECENTS_ANIMATION_STARTED rather than _INITIALIZED, to be consistent with its javadoc and TaskAnimationManager#isRecentsAnimationRunning(). This also ensures we can correctly calculate continued quick switch (see above).
- Call cleanUpRecentsAnimation() before creating a new one in TaskAnimationManager. This ensures that the previous listener doesn't immediately cleanup the new gesture when it gets onRecentsAnimationCanceled() due to the new recents animation starting.
Test: swipe to home twice from the app, locally ignoring the onRecentsAnimationStart() from the first one, and ensure the second one responds normally
Bug: 193851085
Change-Id: I76e27c96b54293805546c0d6c82e77f975c69d7a
