A wide variety of gesture navigation bugs were caused if launcher happened to be recreated mid-gesture and we didn't handle it gracefully. Updated lifecycle callbacks to immediately cancel the ongoing gesture if launcher is destroyed.
Fixes: 244593270
Fixes: 257976590
Test: forcefully(programmatically) recreate on every other gesture nav handle touch down; check that following gestures are not broken and animations are not frozen
Change-Id: Ia8e936e26a42cfe26fc6bcd9eefb25d37bc08749
- The intent is not updated in certain cases which means that the
callback may not be made if Launcher gets recreated. Instead
have the tracker manage the set of registered callbacks.
- This change allows AbsSwipeUpHandler to continue to receive
onActivityInit calls even if Launcher restarts, and also to
handle a case where restarting while waiting for a page-settling
callback will continue to finish the gesture.
Bug: 183962705
Test: Force recreate at various points in the gesture
Change-Id: Ib5ead8c868e798e26e56776f57bd715c79d087cd
Bug: 129067201
Test: Open a shortcut on the workspace, go home
Change-Id: If5d3c3e8e93f09af50aa4994094657347890ef45
Signed-off-by: Winson Chung <winsonc@google.com>
Instead, all callers should use EXTRA_SCHEDULER_CALLBACK, set via
addToIntent(), to provide a callback for the next handleIntent().
The updated runCallbackWhenActivityExists() will do that for the
caller if the activity doesn't already exist (otherwise it will
run the callback synchronously as before).
Bug: 151389129
Change-Id: Idbec264354fd6de166ff3bae98249230078d5674
The flake had disappeared, perhaps because of this logging, or,
hopefully, for some other reason.
Bug: 148313079
Change-Id: I636783d5fc71474dd443c143289c3ff74651835e
- Immediately callback when scheduling activity tracker callback and the
activity already exists
- Remove LauncherInitListenerEx, it was only used to update the prediction
ui state, but not all of the callers of the launcher activity init
listener actually needs this (ie. Go doesn't have overview predictions,
overscroll input consumer/touch interaction service doesn't need it.)
Instead we only call it in the places we need it LauncherSwipeHandler (for
swipe up) and OverviewCommandHelper (for the nav bar button).
Bug: 141886704
Change-Id: I890a45e658be813e99b2a02f179fce611ede9ce8
> Using a common class for both Launcher and RecentsActivity
> Removing static refenrece to LauncherModel and using a common pattern for
tracking activities
Bug: 141376165
Bug: 137568159
Change-Id: Ic1897abe6913ec78e25725118eedf5b468d5ec70
