When you swipe up to overview from home, we should allow touches on
recents even if the overshoot animation isn't finished. If the
touch is below the all apps progress, we continue to intercept to
allow for double swipe up.
Bug: 80093992
Change-Id: Ifdca61e7cfc1f7a713c067596cc0c1bd3154b44e
- Use OvershootInterpolator based on velocity (consistent with swiping up
from home)
- Scale down recents as well, to be consistent with adjacent pages scaling
up when you launch a task
Bug: 109709720
Change-Id: Ie47309058ccf673a4b86c40c843c415beb2d8dc7
* changes:
[automerger] Adding a pending invisibility flag, which is used to indicate that the launcher is not really invisible, but consider it invisible for window transitions am: 1c63c72c1a
Adding a pending invisibility flag, which is used to indicate that the launcher is not really invisible, but consider it invisible for window transitions
is not really invisible, but consider it invisible for window transitions
When a recents animation is cancelled, the callback can be received before or after the
wallpaper animation. To ensure that wallpaper animaiton runs properly, we keep the launcher
forceInvisible=true, only for that particular animaiton and false everywhere
Bug: 109735443
Change-Id: I5b22cc3327c8cd53a836d10e09fc88ae103becfc
Context: onResetOverview callback should be called the moment launcher state
exits from OVERVIEW.
More context: When user drag and drop from overview, and happens to launch
an app immediately after dropping the icon before animation finishes,
that app launch is labeled as OVERVIEW and not HOME.
Bug: 109747805
Change-Id: I24dc8681d6c51dfd2043fe71a1a81d6e96027ef4
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
> Using white scrim on adjescent tiles in overview
> Using a ligher scrim in dark-theme+dark-text
Bug: 80253867
Change-Id: I3f257d3addaca8bc5970a61722f5ae0e7af89382
When a app is restored, it may not be in exactly the same state as it was when backed up.
Some components might be missing, and some shortcuts may be disabled or unavailable
Bug: 63525806
Change-Id: I09e6c0e9a9d2c1e8ccd73430f94bd065bdf2718e
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
> Fixing PagedView resetting the currentPage, if scrollToPage was called before first layout
This causes quickscrub to jump back to the current task if launcher activity was dead.
> Fixing missing callbacks in DeferredTouchConsumer causing missed quick scrub flings
> Sending the resents animation callbacks on the motion queue thread, to avoid synchronization
issues with sysui callbacks.
> Waiting until the recents animation is received before starting the scale down animation
> Calculating the offset for quickscrub statically incase launcher activity was dead
Bug: 80214390
Change-Id: I1b7d00b7b266655a92fcd6239f25ba191655150f
Bug:62372639
Context: only noticeable on large form factor AND Large display setting
Ceiling operation is needed to calculate offset of the drawing.
Change-Id: I7c77fa53f0811990b8cfdc3a12e2b43eb4d2d73e
Also fixes task position being incorrectly reported specifically for
swipe events due to using stale getCurrentPage().
Bug: 72222505
Test: Manual
Change-Id: Ic79b67f8a6ffbfabc397b411b14afc309405197e
It was obstructing views under it.
Solves both Talkback and Switch Access issues.
Bug: 80192025
Test: Manual
Change-Id: Ia7fad91e1fcb857afbf68f879550c670279cee68
Previously we were logging new states as we swipe past them; now we just
log the start and end states when lifting your finger.
Bug: 80102083
Change-Id: Icec6c3dab1441023a3cdcadb7b56ecef8313cb8c
Tony
Android Build Merger (Role)
TreeHugger Robot
Sunny Goyal
Winson Chung
Hyunyoung Song
Mehdi Alizadeh
Vadim Tryshev
Jon Miranda
Tracy Zhou