This layout is handled by the provider of the hints now.
Bug: 132886768
Test: manual
Change-Id: Ifc0db2395a7503b1b03dcb796961ef6647c0413b
(cherry picked from commit f3231f417d)
> Only creating task overlay for one view at a time
> Fixing setOverviewStateEnabled called twice when going
between OVERVIEW and BACKGROUND state
Bug: 132815672
Bug: 122345781
Change-Id: I51ac5b0744af87194eca08e07fd2c75b8fa0d3e0
Maintaining a boolean corresponding to overview or QuickSwitch which
updates the visuals for RecentsView accordingly
Bug: 134166337
Change-Id: If1aec99257de4db1796335f2cf39d2d35789915b
When ending in recents, we reapply the state - therefore, it's important
to make sure we are in OverviewState before onSwipeUpComplete(). This is
done by mLauncherTransitionController, which sets OverviewState on end.
We already force mLauncherTransitionController to end before calling
onSwipeUpComplete(), but in this case we were calling cancel() and
setting mLauncherTransitionController = null, which meant we could never
call end() on it. Instead, we should always call end() if we set it to
null.
Also ensure mLauncherTransitionController is created even if the gesture
is completed, if an existing controller isn't already running. This can
happen if you swipe up quickly enough that we get onGestureEnd before
launcher is drawn, and in that case we still want the launcher component
to animate once its ready. This is even more important for 2-button
mode, because again, we rely on mLauncherTransitionController to set the
state to OverviewState before we reapply it.
Finally, clarified some methods by renaming "swipeUp" to
"swipeUpToRecents".
Bug: 132757019
Change-Id: Ieb24a4f36a39780e5d64d7bc312791608db474d1
State UI depends on visible content, which can change due to predicitons.
Reapplying the state whenever then happens ensures that we are in correct
start UI
Change-Id: I9f195a92b747fda8a5b217dc960f230d7a695255
This can happen if we get onApplyWindowInsets() after onGestureEnded().
In that case, we can get into some bad states because the running
animation is overwritten and thus can't be canceled.
Bug: 134096917
Bug: 133806285
Change-Id: Ic517d68a46a4446ca382445df1ba62c26e8243ad
* Mostly value changes.
* Added a way to round the corners during swipe up to home animation.
Bug: 123900446
Change-Id: Id61d241d919ba51ced0633585e36b7d93efe30b0
Also, when landing in recents, snap to the nearest page so that swipe up
consitently goes to task 0 instead of sometimes scrolling to task 1.
Bug: 133518678
Change-Id: I63a161a9f1f87266d3c3fc71c98cd5fc5e2f8874
notifying LauncherCallback accordingly
During quick switch Launcher can get resumed only to be paused again
when launching a new app. Updating the logic for deferred resume to
account for that and moving some additional calls to deferredResume
Bug: 134062513
Change-Id: Ia607f178bc17d45d53fb032a06cd70f9abc6b513
When device is locked, only scale down the top task as a response to
the user interaction. When user flings or lifts his finger, the task
is dismissed to go to the lock screen
LockScreenRecentsActivity is an empty activity which starts on top of lock
screen and finishes immediately. This allows us to start a recents transition
with just the top activity as the animation target. This target is then used
for swipe up interaction
Bug: 133167096
Change-Id: I466ed142ea33d626c78cb9cc5f6311bad26b8d98
When the container was present, but empty, it was showing it's background.
Bug: 133783088
Change-Id: I97b65435d66e9ced7f5487dc50a00665794f8fcd
Tested: manual
- Previously, we clamped the progress to 1 when reaching mTransitionDragLength.
Now, we allow dragging all the way to the top of the screen, and store this
new top progress in mDragLengthFactor (> 1f).
- Because the launcher animation controller is inherently bound to a progress
between 0 and 1, we have to do a bit of trickery involving interpolators.
Specifically, we normalize the progress to 0 to 1 by dividing by
mDragLengthFactor, but then we set the interpolators to multiply their
progress by mDragLengthFactor. The result is that the animation progress
appears to go from 0 to mDragLengthFactor, just like the window progress.
- To avoid scaling too small, we start interpolating the progress at a certain
point, ending at a specified max progress when reaching the top of the screen.
Bug: 131741395
Change-Id: Ie8b4b56d37249cd1456f93c110c26c78fe052dc0
This eliminates an unreliable timeout.
Also removing an unnecessary check for harness that is done by the
called method.
Change-Id: If954580060415cbb2952532c16ea0ae4dc7b9469
If we are cancelled after the animation has completed, but before the deferred frame
was captured, we set the state as cancelled, and start the new consumer with the
existing recents controller.
But after the deferred frame, we finish the controller (and since the state was set to
cancelled, do not launch the new task)
Bug: 132756514
Change-Id: If30af713c76b6d895d0b01b93d31c0e1403b7214
TreeHugger Robot
Zak Cohen
Winson Chung
Sunny Goyal
Tony Wickham
Govinda Wasserman
Jon Miranda
vadimt
Bill Yi