6

I'm trying to find the official documentation about the Android Application class lifecycle. Apparently, for what I found on StackOverflow here and here the Application class can be killed if the system needs memory. Even this tutorial says so.

But few things irritates me a bit about this:

  • I can't find an official documentation telling me that yes, the Application class can be killed on low memory.
  • I can't find any official diagram representing the Application lifecycle neither.
  • I can't find any proper callback to use when the Application class is killed except onLowMemory(). Does it mean that I have to use this method to persist my data?
  • If the Application class is killed on low memory pressure and the app comes to foreground again, how can I know in its onCreate() that the app has been recreated after a system kill? In an Activity I would test the savedInstanceState, but as far as I know there is nothing similar in the Application class.

Thank you for your enlightenments.

Community
  • 1
  • 1
E-Kami
  • 2,529
  • 5
  • 30
  • 50
  • what about `onTrimMemory`? – pskink Feb 19 '16 at 05:40
  • Have you seen http://stackoverflow.com/questions/8515936/android-activity-life-cycle-what-are-all-these-methods-for? – Maytham Fahmi Apr 12 '16 at 11:16
  • http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle – Maytham Fahmi Apr 12 '16 at 11:17
  • this is not directly related but might be useful http://hsc.com/blog/best-practices-for-memory-optimization-on-android-1 – Maytham Fahmi Apr 12 '16 at 11:19
  • another interesting link http://stackoverflow.com/questions/4585627/android-application-class-lifecycle?lq=1 – agonist_ Apr 12 '16 at 11:23
  • Thanks for your links – E-Kami Apr 12 '16 at 12:39
  • Java classes (like `Application`) are never "killed", for any conventional definition of the term "killed". A singleton instance of the `Application` class (or a custom subclass) is created as part of starting up your process. That instance remains until the process is terminated. – CommonsWare Apr 13 '16 at 11:59
  • @CommonsWare `That instance remains until the process is terminated` what kind of process are you talking about? If you talk about the app being killed then your assumption is wrong. The `Application` singleton can be terminated even if the app is alive. – E-Kami Apr 13 '16 at 12:07
  • 1
    "what kind of process are you talking about?" -- an operating system process. "The Application singleton can be terminated even if the app is alive" -- you are welcome to publish a sample app that demonstrates this. Perhaps you have a different definition of "alive" than what computer programmers use. For example, the overview screen (a.k.a., recent-tasks list) does not show running processes; it shows recent tasks. – CommonsWare Apr 13 '16 at 12:12

2 Answers2

4

I can't find an official documentation telling me that yes, the Application class can be killed on low memory.

Below are the references to where it's been stated:

I can't find any official diagram representing the Application lifecycle neither.

This is a reasonable observation... Although the following is opinion-based, my best guess is that such a diagram would contradict the Android's multitasking "philosophy" as described in the last reference provided:

"A key to how Android handles applications in this way is that processes don't shut down cleanly. When the user leaves an application, its process is kept around in the background, allowing it to continue working (for example downloading web pages) if needed, and come immediately to the foreground if the user returns to it. If a device never runs out of memory, then Android will keep all of these processes around, truly leaving all applications "running" all of the time."

I can't find any proper callback to use when the Application class is killed excepted onLowMemory(). Does it mean that I have to use this method to persist my data?

Regarding onLowMemory() whose description is quite straightforward, are we talking about a background process or foreground UI?...

If none of application Activities is in foreground and OS is low on memory, it may kill the app so that none of the Application's or the app component's (Activity, Service) callbacks will be invoked. That said, (since you're dealing with Activities) I recommend to store all persistent data as per the documentation, in onPause().

If the Application class is killed on low memory pressure and the app comes to foreground again, how can I know in its onCreate() that the app has been recreated after a system kill?

You can't recognize it in Application's onCreate().

Onik
  • 19,396
  • 14
  • 68
  • 91
  • when an app comes to the foreground after its process has been shut down, will the application class's `onCreate` method be called before the launcher/main activity's `onCreate` method? – the beest Sep 11 '16 at 18:22
  • 1
    @the beest Of course, first an `Application` instance is instantiated, then the other app components (`Activities`, `Services`) are created. – Onik Sep 11 '16 at 18:33
1

As far as I know, you can't handle the application killed event. Here is a quote from the Application's onTerminate method:

This method is for use in emulated process environments. It will never be called on a production Android device, where processes are removed by simply killing them; no user code (including this callback) is executed when doing so.

The general idea is that you shouldn't care whether the application was killed or not. If it was, the OS will restart the app next time it is needed otherwise it will be resume (and you'll use the Activity / Fragment lifecycle events to achieve this).

What data do you need to store - is it possible to store it earlier (when it is received from web service and so on) instead of waiting for the last moment?

Samuil Yanovski
  • 2,837
  • 17
  • 19
  • I use to store my singletons which need to keep their reference across all my activities. Some of them are not `Parcelable` and cannot be converted to it. I know that I cannot rely on `onTerminated` but what irritate is the lack of official documentation about the `Application` lifecycle – E-Kami Apr 12 '16 at 12:39
  • If your Application is killed, all singletons will be gced too. Aren't you able to recreate them the next time they are needed? As an alternative, you can try Dagger(http://google.github.io/dagger/) and inject the singletons wherever you need them (you can mark them as singletons so Dagger will make sure a single instance is used). – Samuil Yanovski Apr 12 '16 at 12:42
  • Yes I know they will be gced, what I want to know is why it's the case (from official sources). And no, I'm not able to get them after being gced. Using dagger is not yet a solution for me as it's just a matter of bypassing the problem. Plus I'll have some hard time with the new upcoming Jack compiler and Dagger. – E-Kami Apr 13 '16 at 11:41
  • What do you mean by "why it's the case"? When your application is killed, the whole app process is destroyed, so everything your app has allocated will be gced and recreated on the next app start from scratch. – Samuil Yanovski Apr 13 '16 at 11:58
  • > `When your application is killed, the whole app process is destroyed` That's exactly the point, the application **class** can be killed even when the app process **is not** destroyed. Even when the app was in foreground the whole time. Many users trust that the `Application` class is safe, it's not at all and this assumption come from the lack of documentation about its lifecycle – E-Kami Apr 13 '16 at 12:04
  • I haven't experienced this behavior - getting the application killed while things are still running. According to the docs (http://developer.android.com/reference/android/app/Activity.html#ProcessLifecycle), the OS can kill an activity's process if needed. So if you run multiprocess app your App object can be in a process running only background activities and be killed - this is just a theory, though. – Samuil Yanovski Apr 13 '16 at 17:40