2

I'm unable to find good documentation on an Application's long term lifecycle.

If I have the app running, hit the home button, and then click on the app's launcher icon the Application's onCreate is not called and the front Activity's onResume is called. But presumably if I wait long enough at some point clicking the launcher icon will call Application onCreate and the MAIN LAUNCHER activity is started. When does this happen?

When I go through the apps in the Recents list if I click on a really old app that I haven't used in a month the app does not return to its previous state, instead the app goes through its startup. So it seems at some point apps move from a saved state to no saved state. When does this happen?

If the app gets killed due to memory pressure presumably the savedInstanceState bundle is saved and Activity onResume is called, but does Application's onCreate get called at that point? How long is the bundle saved for?

miguel
  • 16,205
  • 4
  • 53
  • 64
  • possible duplicate of [Will 'Bundle savedInstanceState' be alive after Application is being killed?](http://stackoverflow.com/questions/16837595/will-bundle-savedinstancestate-be-alive-after-application-is-being-killed) – Morrison Chang Jul 01 '15 at 19:36

2 Answers2

4

But presumably if I wait a long enough at some point clicking the launcher icon will call Application onCreate and the MAIN LAUNCHER activity is started. When does this happen?

These are separate issues.

The Application singleton is created shortly after the process is forked, as part of spinning up a new process for you. This will be triggered when something needs your app to exist (e.g., user taps on the launcher icon) and your process does not already exist. Processes do not live forever. How long any given process remains in memory depends on a variety of environmental factors.

Whether the launcher activity resumes an existing task, or whether your task is reset, depends upon whether the task exists (i.e., did the user swipe the task off the recent-tasks list) and how long it has been since the user left the task. A task is considered "alive" for about 30 minutes, though there are manifest entries that you can use to try to adjust this a bit.

So it seems at some point apps move from a saved state to no saved state. When does this happen?

About 30 minutes (see previous paragraph).

If the app get's killed due to memory pressure

I presume that by "app get's killed" you mean "the app's process is terminated".

presumably the savedInstanceState bundle is saved and Activity onResume is called, but does Application's onCreate get called at that point?

Yes, because a new process needs to be created for you.

How long is the bundle saved for?

About 30 minutes (see above).

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Where does the 30 minutes come from - experiment or referenced in either kernel or framework code.? – Morrison Chang Jul 01 '15 at 19:53
  • @CommonsWare when you launch inactive app in recent-task list in more than 30 min, Android should recreate the top most task activity, right ? And you are saying it will happen without re-delivering a bundle ? What if user navigates back thru stack, will other activities be re-created same way (no bundle) ? – kiruwka Jul 01 '15 at 19:55
  • @MorrisonChang: I read it somewhere in the docs when researching the tasks chapter for my book. I had always thought that the rule was "if it's in the recent-tasks list, then it's a recent task". That's not the case, particularly on Android 5.0+ with the endless overview screen. Unfortunately, I don't have a cite handy at the moment, and it's not coming up in a quick scan of the likely spots. – CommonsWare Jul 01 '15 at 19:57
  • @kiruwka: "when you launch inactive app in recent-task list in more than 30 min, Android should recreate the top most task activity, right ?" -- to be honest, I forget. Tasks make my head hurt. "And you are saying it will happen without re-delivering a bundle ? " -- no, the original scenario from the OP was tapping the launcher icon. There, if the task is older, we start the task from scratch. – CommonsWare Jul 01 '15 at 19:59
  • 1
    @MorrisonChang: Ah, found it, buried in [the `alwaysRetainTaskState` attribute docs](http://developer.android.com/guide/topics/manifest/activity-element.html#always): "Normally, the system clears a task (removes all activities from the stack above the root activity) in certain situations when the user re-selects that task from the home screen. Typically, this is done if the user hasn't visited the task for a certain amount of time, such as 30 minutes." – CommonsWare Jul 01 '15 at 20:02
  • @CommonsWare Assume the app is in recent-task list. The app's stack is activities A-B (B visible on top) 1. case of < 30 min. Tapping launch button and opening it from recent tasks should be equivalent, correct ? 2. case of > 30 min. What would be the difference between launcher icon / and tapping app in task ? What exactly does "we start the task from scratch" mean in terms of intents/bundles. Many thanks. and +1 – kiruwka Jul 01 '15 at 20:04
  • @kiruwka: "1. case of < 30 min. Tapping launch button and opening it from recent tasks should be equivalent, correct ?" -- correct. "What would be the difference between launcher icon / and tapping app in task ?" -- launcher icon launches the app, as if there were no task (task is reset). And, as previously noted, I forget off the top of my head the behavior of the older task when launched from the recent-tasks list. – CommonsWare Jul 01 '15 at 20:09
  • @CommonsWare ok, thanks for clarifying what you can, very helpful. It makes my head hurt all the time too. – kiruwka Jul 01 '15 at 20:11
  • @CommonsWare my phone's default "clock/stopwatch" application keeps its state(timer) no matter how long its in the background. When I restore it from recent tasks or via launcher it shows correct time passed since start, after a few hours. How can this be done, given the task is supposed to be "reset" ? Also, it works even if I remove it from recent-tasks list completely. Don't believe they use persistent storage for that. – kiruwka Jul 02 '15 at 07:49
  • @kiruwka: "my phone's default "clock/stopwatch" application keeps its state(timer) no matter how long its in the background" -- you are certainly welcome to persist information related to your state to a file, database, `SharedPreferences`, the cloud, etc. "Don't believe they use persistent storage for that" -- you are welcome to believe whatever you want. – CommonsWare Jul 02 '15 at 10:34
  • @CommonsWare you said that Application startup is a separate issue. But once the system kills the task wouldn't the process be marked as empty as described in the process lifecycle docs and make it likely that the process will also be killed? Assuming no other tasks or Services. – miguel Jul 02 '15 at 19:03
  • @CommonsWare is there a possibility that after the task is killed after the 30 minute period, if the task is relaunched that Application's onCreate will not be called? – miguel Jul 02 '15 at 19:06
  • @miguel: "But once the system kills the task wouldn't the process be marked as empty as described in the process lifecycle docs and make it likely that the process will also be killed?" -- I know of no way to get rid of a task without also getting rid of the associated process (barring possible interference from services). There might be one, but I have not run across it. "is there a possibility that after the task is killed after the 30 minute period, if the task is relaunched that Application's onCreate will not be called?" -- `onCreate()` is tied to the process, not the task. – CommonsWare Jul 02 '15 at 19:36
  • @CommonsWare Sorry for being dumb, but the answer to miguel 's 2d question is yes or no ? I.e. "onCreate() is tied to the process, not the task", so if the task is reset after 30 min it is killed (with the process as you explained) and Application's onCreate *will be* called on re-launch ? – kiruwka Jul 03 '15 at 10:16
  • @kiruwka: "the answer to miguel 's 2d question is yes or no ?" -- the answer is "the question has no answer, because `onCreate()` on `Application` is not tied to tasks". – CommonsWare Jul 03 '15 at 10:42
  • @CommonsWare Ok. Could you please re-iterate on what happens to the process and the task when the task is "reset" after 30 min ? – kiruwka Jul 07 '15 at 07:11
3

Each application installed on the device runs within its process.

  1. If you enter the application for the first time, the following sequence is called:

    • Application.onCreate()
    • YourFirstActivity.onCreate() (provided that the YourFirstActivity is declared in AndroidManifest.xml)
    • YourFirstAcitvity.onStart()
    • YourFirstActivity.onResume()

  2. If you click the Home button, the application goes to background and the following callback methods are called:

    • YourCurrentActivity.onPause()
    • YourCurrentActivity.onSaveInstanceState() - this invocation is not specified exactly but you can assume that by the onStop() method is called in most of the cases the onSaveInstanceState() should be called.
    • YourCurrentActivity.onStop();

While the application is in background it is not specified how long it will be there.

It is up to the System to maintain it in background.

Many applications, while your is in background, perform periodic syncs, run scheduled services or simply run in foreground when launched and for that purpose the Android OS must somehow find memory to execute all this logic. Thus, if there is a shortage in the required memory then the OS kills processes (e. g. your application).

So if you hide your application to the background and click on either the application launcher icon or return to it from Recent apps list immediately, the following sequence of callback methods are executed (assuming that you hid the app while being in YourCurrentActivity):

  • YourCurrentActivity.onRestart();
  • YourCurrentActivity.onStart();
  • YourCurrentActivity.onRestoreInstanceState();
  • YourCurrentActivity.onResume();

However, if you do not reenter the hidden application for a longer period then it is high probability that the OS has already killed your application in favour of meeting other applications requirements.

If this happens the following sequence of callback methods are called:

  • Application.onCreate()
  • YourCurrentActivity.onCreate();
  • YourCurrentActivity.onStart();
  • YourCurrentActivity.onResume();

Notice please that it is still YourCurrentActivity that you left when hiding the application to the background.

The following sequence is executed because System creates new process for your application as @CommonsWare points.

How to prevent the app from being killed by the System? (Android - implementing startForeground for a service?)

Hope this helps somehow.

Community
  • 1
  • 1
dawid gdanski
  • 2,432
  • 3
  • 21
  • 29
  • So if my application has been killed by the OS after I previously left it, why wouldn't "YourFirstActivity" get called first when it's reopened? I have code in my first activity that sets variables and is critical to the use of the app. Is there any way I could force the app to use my first activity open reopen? – justColbs Feb 15 '19 at 22:37