I see frequent posts stating that file writing should be done in a background thread, even when the app is shutting down (
even when the app is shutting down (onStop)
onStop() is a method on
Activity. It will be called when the activity is no longer visible. That may or may not have anything to do with whether the app is "shutting down". For example, transitioning from one activity to another triggers
onStop(), as do configuration changes (by default).
Surely onStop is the one UI call where Android should, perhaps must, be lenient in giving the app time to complete critical work.
It is not a question of "leniency".
onStop() is called on the main application thread. Anything you do on the main application thread ties up that thread, preventing Android from doing other work on that thread. Since the UI is driven by the main application thread, your UI will be frozen during the period of time you are tying up the main application thread in
Note that this is not unique to
onStop(). Any place where you tie up the main application thread is a place where the UI is frozen. Android developers have adopted the term "jank" to specifically mean this behavior.
You may feel that 200ms of a frozen UI is perfectly acceptable. Other developers may not. Users may or may not.
But does that matter, during onStop? During onPause that would be bad, but what about onStop?
In many cases, it does. Just because the
onStop() activity is no longer in the foreground does not mean that none of your activities are in the foreground, unless you only have one activity and this isn't a configuration change.
that Android takes the existence of that running thread into consideration, when deciding whether it is okay to kill the app
It doesn't, unless that thread is being managed by a
Service (in which case, Android takes the
Service into account, not a thread).
To turn the tables, I would be keenly interested in any evidence that you have that Android will terminate your process within ~200ms of
onStop() being called. Otherwise, your thread will run to completion without issue.
I am specifically interested in the failure of the docs I've seen to discuss the different nature of onStop
That is because
onStop() is not different, in the eyes of everyone else. You are welcome to believe that it is different, but please do not expect everyone else to "retcon" what has already been written about Android app development to adjust to your worldview.
Evidence that it is bad to delay the return from onStop by up to 200 ms.
"Bad" is a subjective description. What can be stated is:
onStop() is called on the main application thread (to prove this, log the thread IDs)
tying up the main application thread prevents other work from being done on that thread (fundamental to how threads operate)
Android aims to update the UI on a 60fps basis, or ~16ms/frame
~200ms is ~12 frames at 60fps (long division)
When an app returns from onStop, the act of returning is a statement from the app to the OS that the app can now be safely killed.
An "app" does not return from
onStop() is a method on
Activity. An app may have zero, one, or several activities.
onStop() is loosely related to the application moving to the background, but
onStop() will be called in other situations as well, as noted previously in this answer.
If you return, you are telling the OS it can now safely kill you
You are assuming that failing to return from
onStop() would keep your process alive forever.
onStop() is an advisory event, telling you "hey, your activity has moved to the background". How quickly you return from
onStop() does not matter one iota to the OS process that is responsible for terminating processes to free up system RAM.