(Said :Irving Reid in Bug 917764) > Was thinking about this issue last night, related to Mobile behaviour - we > want to save state when the application goes into the background, in case > the OS kills us in our sleep (see for example > https://hg.mozilla.org/mozilla-central/file/e85b0372cece/toolkit/components/ > telemetry/TelemetryPing.js#l963). > > To support this, I think we want event-specific control of how long the > timeout is, and whether we crash on failure. I suppose we could use a > parallel implementation for the go-to-sleep use case rather than making this > one more complicated.

tl;dr To work well with Android, we should save state in the background rather than at shutdown time, and take reasonable (but not extreme) care to make sure that saves are complete before we return from our activity's onPause() handler when the framework calls it. Note that our application can continue using CPU after onPause(), though we will likely run at lower priority. The purpose of my request was to make sure our Async tooling supports the use case of "Make a serious attempt at completing all these async operations, but let me continue running even if they don't complete." The longer answer is in the details of the Android application life cycle; see https://developer.android.com/guide/components/activities.html#Lifecycle and https://developer.android.com/reference/android/app/Activity.html#onPause%28%29. There's a reasonable summary at http://stackoverflow.com/questions/14375720/android-destroying-activities-killing-processes. Oversimplifying, when an Android activity (roughly, an application) is no longer the "most visible" running activity, the framework calls its onPause() method; when it becomes not-visible-at-all, the framework calls onStop(). In versions of Android except Honeycomb+, the OS may kill the application without warning any time after onPause(), so developers are told to make sure all state is saved before returning from their onPause() handler. Apparently, in Honeycomb and later the platform tries to guarantee only applications that have received onStop() are killed. Under extreme memory pressure these guarantees don't hold, so the application could actually be killed at any time. I haven't found any documentation of a hard timeout on the onPause() handler, though the documentation does say that it should be fast. https://groups.google.com/forum/#!topic/android-developers/LvU1j1fbtLk suggests that a slow onPause() handler will prevent the next application from receiving focus for up to 1/2 second.

Actually, that's something that can already be done without changing AsyncShutdown at the moment.