Most reliable way to do ~200 ms work in Android onStop -

i see frequent posts stating file writing should done in background thread, when app shutting down (onstop) -- if work critical app.

i'm puzzled this. surely onstop 1 ui call android should, perhaps must, lenient in giving app time complete critical work.

i concerned performing critical work on background thread, not inform os the work critical, , needs completed.

there several related aspects this:

----- bothering me; reason wrote question -----

1. is reliable critical work on background thread, after allowing onstop return? doesn't return of onstop signal android app has finished critical, , app function correctly when resumed even if android kills it?

(in other words, seems me advice [to critical work in background thread] wrong. i'm trying find evidence 1 way or other. why wrote question.)

---

----- existence of evidence favors background approach? -----

2. evidence if follow advice, , work in background thread, android takes existence of running thread consideration, when deciding whether okay kill app. [if writing mobile os, wouldn't give existence of background thread weight. suspect complex apps have background threads still running.]

3. evidence bad delay return onstop 200 ms.

---

----- or existence of evidence okay in foregrround? -----

4. or conversely, evidence doing directly in ui thread okay up reasonable time, , evidence time might considered reasonable.

---

----- or big app writers do? -----

5. evidence approach used highly-downloaded, high-profile apps. stay on ui thread while writing file in onstop, or in background? or use service 100% sure? [i figure android unlikely changed in way screw guys over, unless absolutely necessary.]

note: i've seen lots of opinions. don't need hear more opinions. looking evidence.

note: i'm not interested in hearing advice create service or other solution android keep running. i'm not talking work lengthy enough justify that. i'm talking garden-variety work every significant app does, when informed being terminated.

---

update: appreciate information in 2 responses far, feel 1 essential point being overlooked:

there 1 crucial difference between onstop , other ui callbacks:

when app returns onstop, act of returning statement app os app can safely killed. right? isn't essence of onstop?

therefore, logically follows app should not return onstop until has completed critical work.

(and yes, 1 should design app such completion of critical work can done possible. lets not lose main point here. if return, telling os can safely kill you. if kill immediately, , app state messed because did work on background thread isn't finished, approach flawed. isn't it? i'm trying see wrong in analysis here...)

---

update #2 in discussion @commonsware (see comments under answer), have learned an intentservice accomplishes want, , not require additional permissions asked user.

i thinking of ios, strict background work. believe such scheme require additional app permission under ios. avoid additional app permissions, not scare off users.

so experienced ios app developer, less-experienced android developer, the answer didn't know needed was:

1. unlike ios, intentservice can used, without adding app permission, background work that os continue, after app's activity has been terminated.

because intentservice continue running, , not expensive start, , not require app permission, there no "downside" using intentservice start background work, allowing onstop return promptly, while ensuring critical work done.

i have accepted commonsware's answer.

---

update #3 per @zgc7009's question in comment, , responding comment, should ensure critical info persistently stored @ times. see comments details of not stored, until onstop, caused me post question. advantage of up-to-date approach helps if app crashes.

note: still essential (for reliability) mechanism used save critical info guaranteed complete if app going away. [or @ least "transaction guarantee" data won't half-way altered.] use intentservice part of making happen. (our data serialized xml, our code needs run until has finished serializing critical data, , flushed , closed local file.)

even when app shutting down (onstop)

onstop() method on activity. called when activity no longer visible. may or may not have whether app "shutting down". example, transitioning 1 activity triggers onstop(), configuration changes (by default).

surely onstop 1 ui call android should, perhaps must, lenient in giving app time complete critical work.

it not question of "leniency". onstop() called on main application thread. on main application thread ties thread, preventing android doing other work on thread. since ui driven main application thread, ui frozen during period of time tying main application thread in onstop().

note not unique onstop(). any place tie main application thread place ui frozen. android developers have adopted term "jank" mean behavior.

you may feel 200ms of frozen ui acceptable. other developers may not. users may or may not.

but matter, during onstop? during onpause bad, onstop?

in many cases, does. because onstop() activity no longer in foreground not mean none of activities in foreground, unless have 1 activity , isn't configuration change.

that android takes existence of running thread consideration, when deciding whether okay kill app

it doesn't, unless thread being managed service (in case, android takes service account, not thread).

to turn tables, keenly interested in evidence have android terminate process within ~200ms of onstop() being called. otherwise, thread run completion without issue.

i interested in failure of docs i've seen discuss different nature of onstop

that because onstop() not different, in eyes of else. welcome believe different, please not expect else "retcon" has been written android app development adjust worldview.

evidence bad delay return onstop 200 ms.

"bad" subjective description. can stated is:

• onstop() called on main application thread (to prove this, log thread ids)

• tying main application thread prevents other work being done on thread (fundamental how threads operate)

• android aims update ui on 60fps basis, or ~16ms/frame

• ~200ms ~12 frames @ 60fps (long division)

when app returns onstop, act of returning statement app os app can safely killed.

an "app" not return onstop(). onstop() method on activity. app may have zero, one, or several activities. onstop() loosely related application moving background, onstop() called in other situations well, noted in answer.

if return, telling os can safely kill you

you assuming failing return onstop() keep process alive forever. onstop() advisory event, telling "hey, activity has moved background". how return onstop() not matter 1 iota os process responsible terminating processes free system ram.