tree bcb06024c8dc57954457c1d2bef787b95fadbe1a
parent 0d447c88b8649abf14feb2736d320ccc55f44d03
author Tony <twickham@google.com> 1552587098 -0500
committer Tony <twickham@google.com> 1553010927 -0500

Fix some state issues with home and quick switch gestures

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