Can Android kill the activity without killing the entire process while the app is in the background?

Question

I'm wondering if Android system is able to kill the activity without the entire application process while the app is minimized. From Android documentation we know that onDestroy is only called when the activity is about to be destroyed and the systems guarantees to call this method whenever it is about to kill the activity, it will not be called only in case the entire application process is killed.

So, imagine such a situation - you send the app to the background(minimize) and after some time the os starts to run low on memory and decides to kill the activity, but since the app is currently suspended and cannot execute code it is not able to call its onDestroy method althought it is guaranteed that it will be called before every activity destruction.

So, this kind of reasoning gives me a thought that while the app is in the background os is only able to kill the entire process but not some specific activities. Is my reasoning correct, or did I miss something?

Lorenlorena

This is a good question. It can certainly do this - see the "Don't Keep Activities" developer option, for instance. I'm not sure off the top of my head what it does normally, though, when this option isn't enabled. – Heteropolar

Answer 1

That's true: while the app is in the background os is only able to kill the entire process but not some specific activities.

Lapoint

This is the right answer, Android won't kill only specific components, it kills the entire process. There's a quote from a Google engineer if you dig enough.. – Taproom

@SteveM , MarianPaździoch Thank you for the replies. So, basically the last confirmation - while the app is in the foreground the os is able to either destroy some specific activity or kill the entire process(shouldn't happen that often when the app is active) to free some resource and when the app is suspended it is only able to kill the entire process ? – Lorenlorena

@Lorenlorena It only ever kills the entire process as a memory management technique as far as I'm aware. Selecting "Don't Keep Activities" in the dev option destroys them as soon as the user leaves it, but that's really just a debugging tool. – Taproom

I agree with Steve. @Lorenlorena - you asked about "while the app is in the background" so I answered about background. Now you're asking about foreground? – Kweilin

Answer 2

Your reasoning is correct.

If the user navigates away from the activity/application (e.g. by pressing the home button) then the activity is said to be in the "Stopped" state. (States being "None-existent", "Stopped", "Paused" and "Resumed"). If android get low in memory and needs to kill some processes it will target those processes whose activities are in the "Stopped" state and it kill the whole process (not the activity). Furthermore, it will not be polite when doing so and therefore, will not call the activity's onDestroy() method.

Edit following comments about the confusion of saved state on process death:

If the activiy's process is killed, the system temporarily saves a set of settings outside the activity and using these settings, it recreates the activity the next time it is launched.

For example, just before moving to the "Stopped" state the system calls onSaveInstanceState(Bundle) on an activity that is not "finished" and saves this Bundle outside the activity. The system also does remember that it killed activity's process while it was not finished. Using these two along with other settings (saved outside the activity), the system recreates the activity.

If, However, the activity is finished (e.g. user presses the back button, swipes away the activity's card from the overview window, Activity.finish() is called explicitly, etc), onSaveInstanceState() is not called and the system doesn't save any settings to recreate the activity next time it's launched. It simply creates a fresh one.

This is good news, why? Becuase if it wasn't the case, the developer would have had to stash key state properties manually outside activities and reinstate them when activities are relaunched (that would've been a nightmare)

Shanks

Answer 3

Since there's been much confusion on this issue, in large part due to the confusing state of the official docs in the past, here's what the docs say at present:

The system never kills an activity directly to free up memory. Instead, it kills the process in which the activity runs, destroying not only the activity but everything else running in the process, as well.

This as well as real world observation yields that the answer is no.

https://developer.android.com/guide/components/activities/activity-lifecycle#asem

Taproom

from the same docs as well: However, if the system destroys the activity due to system constraints (such as a configuration change or memory pressure), then although the actual Activity instance is gone, the system remembers that it existed. If the user attempts to navigate back to the activity, the system creates a new instance of that activity using a set of saved data that describes the state of the activity when it was destroyed. – Lorenlorena

@SuperSymmetry but the key question was - if the system is able to destroy the activity while the app is backgrounded. If the app is backgrounded it is suspended and not executing any code, so the system is not able to kill some specific activity since it is not able to call its onDestroy callback although it is guaranteed that it will be called before every activity destruction. This kind of reasoning implies that the system is only able to destroy the entire app process when the app is suspended. Again, sorry for some many question - I came here from iOS world where the things are simpler – Lorenlorena

@SuperSymmetry It is either me misunderstood your reply or you misunderstood my question) If the entire app is minimised and suspended(the process doesn't consume CPU time) then how the system can call onDestroy - the app is not running! Then it should awake the app to call activities onDestroy , but I'm not sure that it works this way – Lorenlorena

@SuperSymmetry on iOS the system gives the app about 5 secs to run in background and then it gets suspended, I guess something similar is used on Android . The app gets suspended and doesn't consume CPU cycles unless you explicitly request for background execution(e.g. using a Service). But if the app is suspended then how activities onDestroy can be called? – Lorenlorena