If we have a startup crash, then the nightly updater doesn't run, and nightly users need to redownload nightly (outside of their nightly install) to get unstuck. There are many possible causes, such as: - Problems with addon registration (e.g. Bug 1358888) - Database migration crashes (e.g. Bug 1246704) - Broken HomeConfig migrations (e.g. Bug 1304777 AND 1264136) - etc In other words: it's really easy to cause a startup crash, which then blocks nightly updates. I wonder if we can offer a mechanism to update nightly outside of starting the main app, which avoids the issue of broken code stopping updates. I don't know where the updater runs and/or how closely it ties into the rest of the Browser, so this might not be feasible. Some ideas: - Add an "UpdateActivity" with a second homescreen shortcut. That activity only runs the updater and does nothing else. It's ugly, but it works. - App shortcut (Android 7.1 and newer) - similar to the above, but less ugly. Both of my suggestions still require users to know that the updater activity/shortcut exists. Maybe we can somehow detect repeated startup crashes, and then launch a Safe Update activity instead?
(In reply to Andrzej Hunt :ahunt from comment #0) > Both of my suggestions still require users to know that the updater > activity/shortcut exists. Maybe we can somehow detect repeated startup > crashes, and then launch a Safe Update activity instead? It might require some modifications to make this useable for other consumers, but the crash loop tracking for the session store (bug 1263110) could be a starting point so we don't have to completely reimplement the wheel. Also one important lesson from that bug: The crash reporter runs in a different process, so we can't directly write to our main shared preferences from the crash reporter. Off-hand, that system could use at least one improvement - at the moment, the crash counter is reset only if we successfully pause and resume the activity without having crashed. We should also think about additionally (or instead?) resetting the counter if we've been running without a crash for a minute or two(?).
status-firefox55: --- → affected
status-firefox57: affected → ---
Hmm - it looks like the update service also runs in its own process. Does that mean it shouldn't be affected by crashes in the main app? If so - can we just make sure the UpdateService is triggered as early as possible during app startup (after which we don't need to care about nightly crashing)? We currently seem to trigger the UpdateService when gecko requests that to be done (won't happen for startup crashes), and we also seem to start it 30s after app startup, via GeckoApp calling UpdateServiceHelper.registerForUpdates() (also won't happen for startup crashes). I'm guessing the 30s delay is to prevent hitting the network / doing additional work while gecko is starting, but we could shift the delay into the UpdaterService (via an Intent parameter?), and start the service immediately on app startup?
Assignee: nobody → ahunt
Some discussion on the delay starts from this comment onwards: https://bugzilla.mozilla.org/show_bug.cgi?id=792992#c18
You need to log in before you can comment on or make changes to this bug.