[guardian-dev] Orbot v14.1.4: The Battle for the Background!

Mark Murphy mmurphy at commonsware.com
Mon Dec 1 18:22:10 EST 2014


I apologize for tuning into this thread late, so forgive me if I cover
ground covered elsewhere in the thread but missed it.

On Mon, Dec 1, 2014, at 10:45, Michael Rogers wrote:
> Maybe I'm misinterpreting the docs - I read the Process Lifecycle
> section as saying that a process may be killed (in the classic Linux
> sense of the word) at any time, but a process hosting a foreground
> activity or service will only be killed under desperate circumstances.

Correct... for the automatic reclamation by the OS. Bear in mind that
the user can get rid of your process -- even a foreground service will
not survive a "Force Stop" from Settings (a.k.a., the Monty Python foot
landing on your app).

> According to the same section, a service is considered to be running
> in the foreground while executing onDestroy(). Since a process hosting
> a foreground service may be killed (under desperate circumstances), I
> take that to imply that onDestroy() is not guaranteed to complete
> before the hosting process is killed.

It is not guaranteed to even be called.

For example, suppose the user is in your app (foreground UI), and a text
message comes in. The user swipes open the notification tray and taps on
the text message notification, thereby open the text messaging client.
Your process moves to the background. The message contained a URL, so
the user taps on the link, opening up a Web browser. Right then, a phone
call comes in. Android may need to terminate a process to free up system
RAM, as its pool of free RAM may have been exhausted by the rapid-fire
forking of new processes (SMS client, Web browser, perhaps other
background stuff), and it may be that your process is the OOM killer's
#1 target. However, an incoming phone call is considered a high-priority
need for a process -- we cannot tell the user "you have an incoming
call, but we need to call onDestroy() on a whole bunch of components,
each of which might take up to 5 seconds before we yank the rug out from
under them, so you cannot take the call just yet, please hold". In this
case, Android will terminate the process with extreme prejudice, and
will not call onDestroy() on the components, so it can use the RAM for
the incoming phone call.

Plus, "Force Stop" does not call onDestroy() on components. And, if you
crash, Android tends to assume that your component has lost its
proverbial marbles, and may not call any further lifecycle methods while
it disposes of the component.

Hence, *usually* onDestroy() will called, but not always. How much
engineering it is worth for these edge/corner cases is largely up to
you.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to Android Development_ Version 6.2: Lollipop!


More information about the Guardian-dev mailing list