IHomeTransitionListener was only used when the visibility state changes, but not
when the taskbar is recreated during rotation. Instead we create a static listener
to keep track of current home visibility state
Bug: 331947346
Bug: 331947116
Flag: aconfig use_activity_overlay staging
Test: Manual
Change-Id: Icf613f7fc4f78e3f76a600202687b069d53a16dd
* Un/Pinning taskbar re-creates controllers which led to
stale state for checking if we are allowing split selection
Test: Crash/immediately going into split no longer repros after
un/pinning taskbar in overview and trying to split
Fixes: 326356246
Change-Id: I06cfc4d1c3c7fe071f04414c3134eaff7960ade6
The values are currently the same for all display and orientation
configurations, but they might change before launch.
There are a couple known imperfections:
* Swiping out of a hotseat app with very low velocity doesn't look
great
* Sometimes, if the window movement reaches its final location faster
than the background is done scaling, there is a small snap in icon
position
Bug: 298089923
Flag: ACONFIG com.android.launcher3.enable_scaling_reveal_home_animation DISABLED
Test: verified with the flag on and off
Change-Id: Id54c7f0a76f62108d8b92a3b5e78634fff64dbef
This prevents taskbar showing up on home screen. We already did this clean
up when the flag is off, so now we're matching parity. Investigation for
root cause is still on-going but for now this will fix the issue for
TEAMFOODers.
Bug: 279514548
Test: See bug for repo steps
Flag: N/A
Change-Id: I9a0c3b56f48b2c7c43e303978699124146c8b61b
This fixes the bug where taskbar shows up on home screen.
Fixes: 314790864
Flag: N/A
Test: From overview, tap on app, then immediately swipe to go home
Change-Id: I3aaa8cbe67edefc43ccd6db90ee7647152a862fc
This is fundamentally caused by the phone device profile not having task bar related attributes, which crashes in icon alignment animation. We had resolved it by skipping this animation based on isPhoneMode check. However, we passed in launcherDp instead of taskbarDp (from TaskbarActivityContext) which doesn't always have the most up to date information in race conditions (e.g. repetitively fold/unfold)
Fixes: 311431054
Test: repetively fold/unfold, make sure it doesn't crash
Change-Id: I65f600112da4123d337b3f59a2fe6dd13ac7af74
This fixes the bug where the flag gets set when user taps on nav handle, which
results in the taskbar animation playing.
Flag: N/A
Test: open app
wait for taskbar to finish stashing*
tap on nav handle
nothing happens (desired affect)
* I will address tapping on taskbar while its animating in a separate change
Bug: 292108880
Change-Id: I75870050225bdd951c69224d272d0bd5a3d6d4ea
With task bar in unfolded state, we animate from app to home by morphing the task bar into the hotseat. In the folded state, the visibility of the hotseat should never be affected by the task bar state.
Fixes: 309477352
Test: Swipe up from app in folded state with task bar / nav bar unification flag on, make sure that the transition is smooth and the hotseat is always visible. Also make sure unfolded state works as usual.
Change-Id: I1064a0c03e8f7539f8ea4d0322f58be9dff8513e
Also set flag to TEAMFOOD.
Flag: ACONFIG ENABLE_HOME_TRANSITION_LISTENER TEAMFOOD
Bug: 306053414
Test: manual
Change-Id: Icf3947e61fa9f20f5b6e5ca2af96e693b55d3edc
* This is specifically when contextual is initiated on home
screen and then user swipes up into overview.
* We no longer want to rely on LauncherStates for split specific
management
Bug: 295981634
Test: Start split on home, swipe up to overview, long press on
taskbar app icons, nothing happens
Flag: ENABLE_SPLIT_FROM_WORKSPACE_TO_WORKSPACE
Change-Id: I9e56ddbe1f536be779d4848769a993724d5395da
Test: manual - have transient taskbar
- have a bubble
- go to overview
- expand bubbles
=> observe that transient taskbar stashes
- collapse bubbles
=> observe that transient taskbar unstashes
- verify that expanding bubbles in app and on launcher
home behaves as expected (stashes taskbar in app and
don't see taskbar or stashed handle on home)
Bug: 284104811
Change-Id: I3d7057ed651e66ab2a0292725f30153ee4d6d51e
ag/23852178 introduced a clean up for launcher state when invoking
transient taskbar. It was checking launcher activity resumed state with
`isResumed()` method. This breaks transient taskbar for desktop mode as
we are marking the launcher activity to be paused using the launcher
flags. `hasBeenResumed()` method is the one we can used instead as it is
checking the launcher flags and not the resumed state of the activity
itself.
Bug: 292266259
Test: open transparent activity on top of launcher
unstash taskbar
go home
Test: move an app to desktop, unstash taskbar
Change-Id: I98d14dbfdde4b857f50e62206fc0f308e8f54231
This flag was not being set in the case where you lock from launcher and
then unlock by tapping on launcheable items from keyguard such as home
controls, notifications, smartspace, etc. This change makes sure we
double check if we are unlocking to launcher or not and then setting
FLAG_IN_APP accordingly.
Test: manual
Fix: 284314711
Change-Id: If46697566d252c649a00a7b3d728a14789dc6aed
* Bubble bar typically follows the behavior of taskbar - if taskbar
is shown, the bubble bar is shown, if taskbar hides, bubble bar
hides.
* The bubble bar has 3 states: stashed, collapsed (unstashed but
the bubbles are not expanded), and expanded. When bubbles are
expanded, this means WMShell is rendering the bubble
expanded view. In this situation taskbar becomes collapsed.
Bug: 253318833
Test: manual - flag turned on - see go/bubble-bar-tests
Test: manual - flag turned off:
- launch an app, ensure taskbar is stashed
- unstash taskbar, drag down on taskbar, ensure it
becomes stashed
- be in an app, unstash taskbar, interact with the app,
ensure taskbar is stashed
- be in an app, unstash taskbar, select an app from it,
ensure taskbar is stashed & app is opened
Flag: WM_BUBBLE_BAR
Change-Id: I7b481d768182c8429160ab4a9b213b885a7d78bc
- The previous call from TaskbarLauncherStateController caused a
regression due to the inability for the code to distinguish
Normal -> Background -> Normal when tapping on the bar area
or from failing to launch a task, so both cases were triggering
the resumed state to cycle and start an animation. For now we can
only handle the task-launch fail case.
Bug: 268448123
Fixes: 281966662
Test: Quickswitch to an activity that finishes when resumed
Change-Id: Ie4692dd85252540ff47633978c0e6e4adbb1bdd0
While in overview, makes the touchable region smaller so touches can go to the window below and trigger tapping on overview to go home.
Bug: 269985301
Test: Manual (TAPL in a following CL)
Flag: none
Change-Id: Ie8c7719090c387f951d78cf0fc47e6d9ed192f27
* Bubble bar typically follows the behavior of taskbar - if taskbar
is shown, the bubble bar is shown, if taskbar hides, bubble bar
hides.
* The bubble bar has 3 states: stashed, collapsed (unstashed but
the bubbles are not expanded), and expanded. When bubbles are
expanded, this means WMShell is rendering the bubble
expanded view. In this situation taskbar becomes collapsed.
Bug: 253318833
Test: manual, with other CLs, see go/bubble-bar-tests
Flag: WM_BUBBLE_BAR
Change-Id: Ic210c382e7482c259ae543a0dc083fe9305cbf5b
- The main issue arises when a task is successfully launched from
overview, but the activity later finishes (ie. during resume) which
prevents the usual logic of resetting Launcher to a good state
(ie. it can get stuck in overview with a blank or empty snapshot)
In this case, the Launch will "succeed" so that onTaskLaunchFailed
is not called, but then also silently fail (launched task finishes
and Launcher is again resumed) before Launcher stops, which does the
usual resetting of the state back to normal state after quickswitching.
This change checks for this case by listening for the activity and
transition state, and in the case where Launcher has not been stopped
or is resumed again after the transition finishes, returns the
user to the default home state.
This primarily only affects quickswitch for now, as other launch
failures leave the user in a valid state (ie. overview) while this
issue will leave the user in background state while quickswitching.
Bug: 268448123
Test: Quickswitch to an activity that finishes when resumed
Change-Id: I7d554f8fd521f7bc480dc06930ad91eeef0f1a1a
The fix caused a flicker tests to fail, but that is specific to the persistent taskbar used in tests only.
Bug: 277470898
Bug: 277003116
Fixed: 277470898
Fixed: 277003116
Test: Flicker tests passes
Test: Manual (http://shortn/_kiAZykhZsp)
Test: Tapl presubmit tests
Change-Id: Ib9daebf3b06af2f1a4a3b7461acf91f204ff281b
This reverts commit 41b580bc63.
Bug: 277942460
Test: tablet/foldable device
check taskbar animation b/w states and during drag
Change-Id: Ib8b362102d08d155d3153b652db47364feb5df0a
This reverts commit ecb55ef471.
Bug: 277942460
Test: tablet/foldable device
check taskbar animation b/w states and during drag
Change-Id: I48e37d58afa6e168a683e1b9c73ae15432920030
Fixes: 277271088
Test: be in app
swipe up from bottom to top of screen without pausing then release
observe taskbar -> hotseat handoff
observe no jump
Change-Id: I2bb9d93d39215ca3653e2e4353391b50b7ab6417
When entering the dreaming state, the TaskbarDragLayer is faded out.
Upon wake up, a slight delay is added to allow the SFPS reader to do
its magic, so the lockscreen-navbar does not pop-in just to be removed
again.
Bug: 271440683
Bug: 275319714
Fixes: 271440683
Test: manual (http://shortn/_cQudGXDSDU)
Change-Id: I34e02f02288bace39626d531d115fc994b11f371
This is a better fit for the signal in launcher, since it identifies
whether the device is awake or asleep, where asleep also inclues AoD
Test: manual, unit tests
Bug: 275319714
Change-Id: I6d6a6694ab018d182606c5554377caec1986bc08
This is a follow-up to ag/21699905, which caused the nav-bar to be visible after a device-restart alongside the hotseat, until an app was launched.
Currently, when restarting launcher (for example a device restart), there is no guarantee when the SysUI flags are received for the first time. The current init-codepath expects the launcher to be fully initialized at the time. From there, only deltas are processed:
- during the initial resume, launcher is not considered active because the screen is still off
- the SCREEN_ON event itself is not processed to update the FLAG_IN_APP
Before: http://shortn/_MGQjGFRIaB
After: http://shortn/_awiv2CxFn9
Bug: 261418621
Test: manual (http://shortn/_ty9EDuLM97), tapl
Change-Id: Ie3b3ba1ebe249efe8fc43850052bc9956cafcd24
The spring animation was getting cancelled by the reset
animation.
Added a check to avoid creating a new reset animation if we
are already animating to the final value.
Bug: 273961611
Change-Id: I3afb62b89b5f6fbe920906499db2497ef8e94069
Flag: ENABLE_TRANSIENT_TASKBAR
Test: stash transient taskbar