tree 1d27c62995a7ce5353e8ba489cb2c9cf7ecb2c0b
parent 9a0d98f48345b5c15d86beb3c80decb15321f5f1
author Tony Wickham <twickham@google.com> 1633481722 -0700
committer Tony Wickham <twickham@google.com> 1633482891 -0700

Fix issues with starting new recents animation before previous onRecentsAnimationStart

- Fix logic for canceling animation for continued quick switch, so that this case (starting a new gesture before onRecentsAnimationStart() of the previous gesture) instead goes to the STATE_FINISH_WITH_NO_END flow.
- Update the end target so that we go to that state instead of always overview state if swipe was past the halfway threshold when we call endLauncherTransitionController(). This is specifically so we don't use OverviewInputConsumer on the second gesture, given the first one was canceled and didn't actually go to overview.
- GestureState#isRecentsAnimationRunning() now checks for STATE_RECENTS_ANIMATION_STARTED rather than _INITIALIZED, to be consistent with its javadoc and TaskAnimationManager#isRecentsAnimationRunning(). This also ensures we can correctly calculate continued quick switch (see above).
- Call cleanUpRecentsAnimation() before creating a new one in TaskAnimationManager. This ensures that the previous listener doesn't immediately cleanup the new gesture when it gets onRecentsAnimationCanceled() due to the new recents animation starting.

Test: swipe to home twice from the app, locally ignoring the onRecentsAnimationStart() from the first one, and ensure the second one responds normally
Bug: 193851085
Change-Id: I76e27c96b54293805546c0d6c82e77f975c69d7a