=> Using the drag slop (currently 10dp), which is the appropriate slop when comparing to the other gestures. Touch slop (which was being used for the Assistant) is only being used for gestures starting from the back button. This means that the delegate was getting triggered much too often (unfair slop competition). This prevents that.
=> Fixed additional bugs with the consumer delegate / sharedState; the shared state notion really only applies to the OtherActivityInputConumer, and it wasn't being propagated from the AssistantConsumer.In addition, the isActive() method is only being used as a proxy for whether or not to use the shared state, so clarified the naming. This fixes another case where touch could become completely stuck and you could no longer swipe up.
=> Modified the effective angle to be 90 degrees down to 20 above the horizontal.
=> Reduced the drag threshold to 55 dps.
=> Known issue: the time threshold requires motion events to be triggered. In practice, this works because the finger doesn't stay completely still, but we should add a timer to update the progress smoothly.
=> Removed pause detector.
Change-Id: Ie23e836c6d778914594774b830c3cd2e7b94eca4
=> bumping detectable region to 48 dp horizontal + vertical within corner
=> centering detectable angle; total 70 degrees (ie. btw 10 off the vertical and 10 off the horizontal)
=> pilfering touch events when slop is passed and assistant gesture is engaged
=> Fixing issue where we were incorrectly using “sharedState” causing incorrect handling of gestures subsequent to AssistantTouchConsumer being invoked (it was forgetting to clear it’s input state and hence reporting “active” when it wasn’t). The symptom was that gestures after the AssistantTouchConsumer would never actually move the active window even though state was being updated; you’d feel the Overview haptic.
=> Devices with large corner radii are still somewhat problematic as the initial touch down often lands high on the display (ie. above the 48 dp region).
Change-Id: I3d5761112f4cb8b7b1eee987de5afe9aee260304
Bug: 128129398
Test: Rotate to landscape, ensure you can use gesture nav
Change-Id: I4630cbae9bf1cbabd83fb72d5eb09c9a435950e9
(cherry picked from commit 38b76942d6)
* 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
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
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
When continuing the gesture, we set mPassedTouchSlop = true in order to
make the second gesture responsive/fluid. However, we only call
notifyGestureStarted() when passing that slop, meaning we don't call it
in this case. Now we call it immediately on touch down when continuing
the previous gesture.
This cleans up a lot of inconsistent state issues, such as not creating
the launcher animation controller as part of the second quick switch
gesture.
Bug: 111926330
Change-Id: I03c3ed9a8d364fbfdc2d04bafb58a63bf61e2f63
In case events come out of order, the list is not properly initialized
which can lead to missing invalid states
Bug: 127282292
Change-Id: I3b4784b8e3eec890e80e62c2ea613e1ba84b6c95
Hyunyoung Song
Adam Cohen
Sunny Goyal
TreeHugger Robot
Tony
Winson Chung
Tracy Zhou