Don't let old Launcher activity interfere with new one
-> Launcher uses a static instance of it's loader (across
multiple activities) since activities can come and go
(configuration change, eg.) but the data model and loading
is static.
-> Currently, this is not robust to a sequence of events that
looks like onCreate(instance A), onCreate(instance B),
onDestroy(instance B) -- depending on the timing of those
calls.
-> This CL addresses a symptom of the above scenario by not
allowing an older Launcher Activity cancel the loader /
clear the callbacks for a newer Activity.
Bug 17679693
Change-Id: I8ece93e288464b0d578b9669c165b67132d997ed
diff --git a/src/com/android/launcher3/Launcher.java b/src/com/android/launcher3/Launcher.java
index 37a7f5c..6780812 100644
--- a/src/com/android/launcher3/Launcher.java
+++ b/src/com/android/launcher3/Launcher.java
@@ -1134,7 +1134,9 @@
@Override
public Object onRetainNonConfigurationInstance() {
// Flag the loader to stop early before switching
- mModel.stopLoader();
+ if (mModel.isCurrentCallbacks(this)) {
+ mModel.stopLoader();
+ }
if (mAppsCustomizeContent != null) {
mAppsCustomizeContent.surrender();
}
@@ -1997,8 +1999,13 @@
// Stop callbacks from LauncherModel
LauncherAppState app = (LauncherAppState.getInstance());
- mModel.stopLoader();
- app.setLauncher(null);
+
+ // It's possible to receive onDestroy after a new Launcher activity has
+ // been created. In this case, don't interfere with the new Launcher.
+ if (mModel.isCurrentCallbacks(this)) {
+ mModel.stopLoader();
+ app.setLauncher(null);
+ }
try {
mAppWidgetHost.stopListening();