Accessing internal objects only on the main thread and after the user has been unlocked.
Bug: 134971634
Change-Id: Iaf6a1e3ab9417836c5d34673997b0a03a76862c1
When attaching recents, translate it offscreen and use a spring to pull it
into position. When detaching, use the same spring to pull it back offscreen.
Bug: 129985827
Change-Id: I05339e2ec0932070365023bfafc83cbf2a4e178e
When Launcher is not focused and we try to dispatch events to Launcher, it
can lead to a inconsistent state. For eg, NavBarTouchController was trying
to take launcher from NORMAL to NORMAL state causing the endCallback to be
called immediately, which in turn didn't clear Swipedetetor state
Bug: 132209249
Bug: 132815672
Change-Id: I82e4fdcb8fd5339e82fc8551f3a6e0b046d906f8
Here's what was happening:
- When animating to a new task, the launcher controller ends first (when
quick switching it likely ends immediately since we're already scaled up).
- Then we get onApplyWindowInsets(), which re-builds the launcher controller.
- Finally, the window animation ends, invalidating the handler and ending
the new controller, which sets the state to OVERVIEW.
To fix this, never create a new controller if it has ever been started.
Bug: 133508173
Change-Id: Ibd0e18e488353df73159ffbdd9a3b335bed57d98
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
