Before, we reset zoom scale to 1 but didn't reset curve scale. Thus,
if curve scale had never been set (i.e. we hadn't yet scrolled recents),
the task view scale would be 0.
Example problem:
1. Open Calculator or other app
2. Force stop launcher
3. Swipe up
The recents-scale-down animation was incorrect because the computed scale
was 0, and thus recents didn't scale down at all throughout the swipe.
Change-Id: I8dd3c73a231033fa633e8df2df3bf9a1c0a67263
- Added QuickSwitchState, which we animate to when swiping right
on the nav bar from NORMAL state
- Task launches when the state transition to QuickSwitchState ends
Bug: 126596417
Change-Id: Id66650401d817703fc6d044fb26a25cccbc07e11
Previously left was considered positive and right considered negative.
Now left and down are negative, and right and up are positive.
For RTL, left is positive and right is negative.
Change-Id: Ia31e8c687c8c2716fc632b2fe88aa8955b934bce
Add AnimationComponents.ATOMIC_OVERVIEW_PEEK_COMPONENT, and rename
previous ATOMIC_COMPONENT to ATOMIC_OVERVIEW_SCALE_COMPONENT.
When SWIPE_HOME is enabled:
- Overview lives to the left of Workspace, which is encoded in
LauncherState.NORMAL.getOverviewScaleAndTranslation().
- Create atomic animation based on ATOMIC_OVERVIEW_PEEK_COMPONENT
and OVERVIEW_PEEK state when swiping and holding from home screen.
Bug: 111926330
Change-Id: Iab6dbef7238dae15b3036d4b2a026b781eee6b4b
States return ScaleAndTranslation instead of float[].
Also separate overview translate interpolator from overview scale interpolator.
Change-Id: I5e65dde3f436055ff5e7f5736f1a4b712377b9cb
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
The reason is that there is no API that reports that an app is grayed.
Not showing DWB toast for apps that ran over their limit because they
shouldn't be in Overview.
Bug: 129067053
Change-Id: Ia04e17aa85ca015b7932496ad5e730fe61b4be69
* changes:
Remove redundant resumeLastTaskForQuickstep() and use resumeLastTask() directly
Fix some state issues with home and quick switch gestures
Apply spring forces to animate to the final position for swipe home
Now that we don't have quick scrub, the only state that has a non-zero translation is all apps,
which just uses that to have a slight parallax. This is much simpler to define in terms of pixels
like other states do.
Change-Id: I108c8505d85591399256b3475f7566ff51e2c5ad
Also remove STATE_SCALED_CONTROLLER_LAST_TASK, which is redundant with
STATE_RESUME_LAST_TASK. Basically this removes a path of unnecessary
indirection now that everything is on the UI thread.
Change-Id: If11fea2d6064ba909a439b9b88d7c80fb1ad9d73
Handle the fact that LAUNCHER_STARTED can come 25ms+ later than LAUNCHER_PRESENT
- Don't call prepareRecentsUi() if we already completed the gesture to go home
- Previously it was possible to get LAUNCHER_PRESENT -> GESTURE_STARTED ->
GESTURE_COMPLETED -> LAUNCHER_STARTED. Because we go to BACKGROUND_APP state in
LAUNCHER_STARTED, this sequence ended up there instead of home (b/124338231)
- Call setupRecentsViewUi() in LAUNCHER_PRESENT instead of LAUNCHER_START
- Because setupRecentsViewUi() sets RecentsView to show the running task, it was
interferring with quick switches that had the state sequence above
Other quick switch fixes
- Set canBeContinued = true for LAST_TASK gesture target. This handles cases like:
switch from task 0 to task 1, intercept and go back to 0 (LAST_TASK), intercept
again to go to 1
- Ignore deferred touch down target if we're continuing the previous gesture
- Set STATE_HANDLER_INVALIDATED as soon as we start finishing recents animation
instead of waiting until the new task is launched. This is what we do when
re-launching the last task, and it allows us to start a new gesture sooner.
One race condition still exists with consecutive quick switches: if you switch to
a new task, the next gesture might get stuck if it starts after finishing the
recents animation but before the task is fully launched/launcher is stopped.
Bug: 124338231
Bug: 111926330
Change-Id: Ia7e1eebe6e81e2f10bb42a10b2f46fd720da0dc1
The corners will be separated with quick switch by detecting at the slop
of the angle from touch down to that position. If over 30 deg then
assistant will be tracked otherwise quick switch while swipe up will not
be tracked at all.
Test: manual
Bug: 112934365
Change-Id: I6a3aeb1509d9706696a30ef1fba3ce7e3e5ec07c
Now instead of an incorrect hack that simulated accelerating to the target,
we actually apply spring forces to make it feel realistic and work no matter
where the target is.
Added two helper classes for this:
- FlingSpringAnim handles the fling, applying friction until reaching the target,
then a spring to pull towards the final position (also applies if fling wasn't
in the right direction or strong enough to reach the target).
- RectFSpringAnim uses 2 FlingSpringAnims (x + y) to animate from a starting rect
to a target rect. It also has an animation to scale from the start rect to the
target rect, sending progress update callbacks to the caller.
Bug: 123900446
Change-Id: Iafa89db1d55c42816acfa9f1bb84a7519b69ff12
Also moving test provider to Quickstep to have access to the new info;
and now Launcher3 doesn't have it.
Bug: 123904290
Change-Id: I653376610e83839d102beb9c0604950dd314e8ba
Benefit! we would not get merge conflict when one of these jars update
and we need to do code merge.
Change-Id: Ia6a4a632474a7b19aaede1d20d1373902da1400c
We generate an event upon every invocation of Overview with at least one
DWB toast.
Bug: 123892673
Change-Id: Ia24f4be8e9f0f6ab6d31095b8367b73fb6c8cd7f
TreeHugger Robot
Tony
Sunny Goyal
vadimt
Bill Yi
Winson Chung
Tracy Zhou
Matthew Ng
Jonathan Miranda
Hyunyoung Song