This allows us to specify when a second animation will handle the overview
animation, so it doesn't conflict with existing state transitions.
Bug: 125362112
Change-Id: I497c02924862bfba558c107bee3c88a9f40ec0f1
- Move the hotseat alongside workspace instead of on top of all apps in xml layout
- Set pivot point of hotseat to match the workspace's, and apply the same scale
- Translate the hotseat with the workspace instead of all apps
- SpringLoadedState does not scale or translate the hotseat
Change-Id: Ic45fe99f83f0e0012afa78073d9577e65da444e2
transition is not complete
> This state change causes the RecentsView to get reset making the first
task visible
Bug: 111404703
Change-Id: I8ff2577bf965fb4cdf736fb18683ded63ade1872
Trigging quickscrub immediately after a previous quickscrub would cause
the controller to cancel even if the state change was from overview to
overview, then controller will not do auto-advancing because it thinks
quickscrub has been cancelled. If the state changes but both are
overview then do not cancel and quickscrub can do auto-advancing.
Change-Id: I309937572ad23eea14662501f41c13cd79dd10ab
Fixes: 110006796
Test: quickscrub, then let go and soon after quickscrub again
This was leading to a pending animation running while the state had changes,
leaving user in an inconsistent state.
Various atomic animation fixes
> Ensuring that there is only one success listener on atomic animation, so that atomic
controller is created only once and to the final mToState
> If atomic controller is already running, skip animating the atomic conmonenets as
part of main animaiton
> Cancel atomic controller if it is going to a different state
Bug: 80549582
Bug: 109583168
Change-Id: Ie7a032e0fa73b1f1c2ef53055c08d16444f0385e
Changing states causing quickscrub to get cancelled and recentsView to
get reset to page 0, causing an abrupt jump.
Bug: 80537625
Bug: 80497058
Change-Id: I19cfe4380bbff15734b9d90dc31596904da27483
When going to a new state, we cancel any currently playing animation. When
canceling the animation, we reset mState = mCurrentStableState. Thus, when
determining the duration of the new animation, we have both state == NORMAL
and mState == NORMAL, leading to a duration of 0 and therefore no animation.
Storing the fromState before canceling/resetting fixes the issue.
Change-Id: I92332deae8058c4dd41212fe7f749955ede28b1c
mState is set when the transition starts toward that state even if it is
never reached. If the animation is canceled, therefore, we should reset
mState = mCurrentStableState since that is the state we came from.
For instance, when swiping up from overview, mState = ALL_APPS, but when
swiping back down we cancel that animation and create the task launch
animation. When creating the task launch animation, we reapplyState(),
which, before this change, was still ALL_APPS instead of OVERVIEW.
Bug: 79935289
Change-Id: I59c5799e92350747e4ef1d99a80ba678a2ce7b98
Add BackButtonAlphaHandler to set back button alpha, instead of setting
it from multiple places.
Also force back button alpha to be 1 if swipe up is disabled (b/80091187)
Change-Id: I49b63a0e6b033a3a947a847669a398f1b9ff0564
When we enter overview (overview appears, workspace disappears):
- Workspace scales down from 1f to .8f with OvershootInterpolator(1.2f) at 200 ms
- Workspace fades from 1f to 0 with OvershootInterpolator(1.2f) at 200 ms
- Overview scales down from 1.33f to 1f with OvershootInterpolator(1.2f) at 200 ms
- Overview fades from 0 to 1f with OvershootInterpolator(1.2f) at 200 ms
When we exit overview (overview disappears, workspace appears):
- Workspace scales up from .92f to .1f with DecelerateInterpolator() at 200 ms
- Workspace fades from 0 to 1f with AccelerateInterpolator() at 200 ms
- Overview scales up from 1f to 1.1f with AccelerateInterpolator() at 180ms
- Overview fades from 1f to 0 with DecelerateInterpolator(1.7f) at 200 ms
Parallax while the finger moves: Workspace translates half the distance as the shelf
Bug: 79776746
Change-Id: I319d982cf202bcd6dbbcd68ffc5c0c7853629c7e
State handlers can now specify atomic and non-atomic components of
their animations to states, which can be specified when creating a
new animation. There is now one atomic animation, when going from
NORMAL to OVERVIEW (and in reverse):
- RecentsViewStateController's animation (scale/alpha) is all atomic
- WorkspaceStateTransitionAnimation has atomic and non-atomic:
- Hotseat and workspace alpha is atomic, as is workspace scale
- Everything else (scrim, translation, qsb and drag handle alpha) is
non-atomic
- All apps progress is non-atomic
Also simplified dragging through overview; no longer pulls against you,
so we use an OvershootInterpolator when flinging instead of our custom
interpolator for the spring effect.
Bug: 76449024
Bug: 78089840
Change-Id: Iafac84d0c2b99ee9cf9dd5b30e2218286713b449
Previously, user-controlled animations weren't properly being canceled when a
non-user-controlled animation started, e.g. when hitting home. Thus, we could
end in the wrong or inconsistent state because the user-controlled animation's
end runnable was still used. Now we add a cleanup callback for when we reset
the user-controlled animation for one that isn't user-controlled.
Also fixed a couple typos.
Tests (easier with animation durations extended):
- Swipe up and hit home before reaching overview -> land on home
- Go to overview, swipe down slightly (before threshold to go to workspace)
and let go -> return to overview without flash (recents was resetting)
- Swipe up, press home while swiping -> goes home, stops responding to drag
- Start dismissing task and hit home before it finishes (or while dragging)
-> goes home, stops responding to drag
Bug: 78249220
Change-Id: If11d8999e3fadba38c987b25af67cd2304cd859b
Some animation might be running from a previous orientation, which can cuase property changes
to get skipped.
Bug: 77848165
Bug: 77774619
Change-Id: I3e198196192746abdd72a1970ff2ef407bf4aff9
> If launcher already started, creating the state transition only after threshold crossed, so that previous animations are not cancelled
> Not posting animaiton callbacks at the front of the queue, as that sometimes causes it get executed before onNewIntent
> Farking the activity as forceInvisible while launching an opaque app, so that quickly pressing home/back runs the reverse animation
> Not running state animations when force-invisible is true
Bug: 77830325
Bug: 77898806
Change-Id: I50a7e915ca35fd6aeb284c8f321ecca74396fe98
SysUI change: ag/3721784, ag/3793664
- Track LauncherState and launcher activity state through callbacks.
- Devise logic to send shelf visibility and height signal to SysUI based
on LauncherState and Launcher activity state.
Bug: 73961893
Test:
- By default, pip shows up right above the shelf.
- Transitioning to all apps moves the pip down as the shelf becomes
invisible.
- Going to any specific app moves pip down. Hitting home moves pip
right above the shelf again.
- Dismissing IME should push PIP down but above the shelf on home
screen, bottom if not.
Change-Id: I1ab6ceb8007a5a7b5d932a456efa0a07f586ea4c
so that the animation is reset when we start a state animation from
launcher
Bug: 74975768
Bug: 75290288
Change-Id: If7f71f087d7bb64fb25c085c476a6fcbc86518e2
- Snap to the next task when quick scrub starts, but don't allow
snapping to further pages until the transition to overview
completes (to prevent overshooting)
- Simplify quick switch to just launch the task that was snapped
to in onQuickScrubStart
- Cleanup some state code
Bug: 70180755
Bug: 74014237
Change-Id: I7a4a0f1a568947b1f5e56a27d7328e47b05a675d
> Finishing the active animation instead of cancelling it. This ansures
that the animation callbacks are called properly and RecentsAnimaiton is finished
> If a transition is already running, using main thread for next transtion so that
this new transition is not started before the last transition is finished.
> If the transition is expected to finish at Launcher, directly use the Launcher
consumer. RunningTaskInfo is not updated until the screen shot is complete.
Bug: 74481901
Change-Id: I2b1128f1f2eff0e6bd94b3adb9cef6ae0578bd0c
Prior to this change:
* User presses home before opening app transition finishes
* Close app transition starts
* AllAppsTransitionController#mProgress = 1.3 (starts offscreen)
* Launcher#onNewIntent makes call to AllAppsTransitionController#setStateWithAnimation
* targetProgress != mProgress (1 != 1.3), so it runs an animator that looks odd
ie. fast duration, only AllApps animates compared to expected full closing app transition
Change-Id: I755787aebf637675cb9aae23fc5784f5a5b6c811
Add OverviewInteractionState to handle setting OverviewInteractionFlags.
Hide back button when in NORMAL state and launcher's window is focused.
Show it when in other states or when launcher's window loses focus.
Change-Id: I35919561b9972789e995f1cc434c23e2afe9e77c
When we get the onQuickScrubStart() or onQuickSwitch() callbacks, we go
to the overview state with a quicker duration (the same used from apps).
Then we follow the same logic as starting quick scrub/switch from apps
except that we allow you to scrub back to the workspace card.
Bug: 70180755
Change-Id: Iebcdcc4c4ad1e1210e2d1c11e5007c27d3c1eef3
Intead of finishing the entire animation (launcher animation and
window animation), we finish just the launcher animation.
Bug: 73071035
Change-Id: Ied84cb641f3cedc367433ad99d21ab1b258ae7f8
> Resetting the state to NORMAL on every onStop so that the user
never starts on the overview screen
Change-Id: If3c17693b7125a3969809e60891a2ab978fe83bc
The app transition might change an object that the new
state depends on, causing an inconsistent state.
Bug: 72816542
Change-Id: Ia6dd52971b52be5589c88f4f6d93d06146fbadab
