Android memory management granularity - Activity or Process?

Question

I am seeing inconsistent documentation and discussion regarding what happens when Android is low on memory and the steps the OS takes to re-claim memory. More specifically, does Android kill at the granularity of activity/fragment, or entire process?

For example, if Activity B is launched in front of Activity A (and both activities are part of the same app/process), can Activity A be killed by the OS while Activity B is in the foreground and the user is interacting with Activity B (assume: screen remains on, current app remains in the foreground, no orientation change occurs)?

This SO answer from 2011 (by Dianne Hackborn on the Android team at Google) suggests that Android kills at the granularity of a process, NOT an activity.

On the Android Developer pages on Recreating an Activity, it says:

The system may also destroy your activity if it's currently stopped and hasn't been used in a long time or the foreground activity requires more resources so the system must shut down background processes to recover memory.

Notice the ambiguity: "the system must shut down background PROCESSES".

On the Android Developer pages for onSaveInstanceState, it says:

For example, if activity B is launched in front of activity A, and at some point activity A is killed to reclaim resources, activity A will have a chance to save the current state of its user interface via this method

After reading through these and many other doc pages and online discussion, it is not clear what the correct answer is.

I also have the same question regarding fragments: Can a backgrounded fragment be killed due to low memory, without its entire process being killed?

Acetophenetidin

Answer 1

Memory management happens at two distinct levels: through garbage collection (recycling unreferenced objects) and at the process level, as explained in this Android blog post. There is no concept of killing just a single activity (remember: Android is based on Linux and Linux has no concept of activities or components, just processes).

This SO answer from 2011 (by Dianne Hackborn on the Android team at Google) suggests that Android kills at the granularity of a process, NOT an activity.

This is still correct.

On the Android Developer pages on Recreating an Activity, it says...

Yes, the 'background processes' it mentions is exactly the process category mentioned in the above blog and the documentation. This refers to activities that previously existed, but are no longer part of the current foreground/visible processes.

On the Android Developer pages for onSaveInstanceState, it says:

Yes, they are discussing the case where you launch an Activity from another process (as is likely when you are using implicit intents). During this time, your process is not the foreground process and therefore is certainly possible to be killed if the combination of foreground activity+foreground services is too much.

I also have the same question regarding fragments: Can a backgrounded fragment be killed due to low memory, without its entire process being killed?

No, fragments cannot be killed due to low memory.

Dhow

That makes sense. I know Linux has no concept of activities, but I wasn't sure if Android added in the ability to kill off individual activities. Thanks for clarifying! – Acetophenetidin

Answer 2

I would err on the side of the Android guidelines and documentation (albeit, it would be great if they were more clear in code documentation and SO answers). From http://developer.android.com/guide/components/tasks-and-back-stack.html :

When the system stops one of your activities (such as when a new activity starts or the task moves to the background), the system might destroy that activity completely if it needs to recover system memory. When this happens, information about the activity state is lost. If this happens, the system still knows that the activity has a place in the back stack, but when the activity is brought to the top of the stack the system must recreate it (rather than resume it). In order to avoid losing the user's work, you should proactively retain it by implementing the onSaveInstanceState() callback methods in your activity.

Propeller

Answer 3

It is "Process" and not "Android Activity". Part of the confusion lies in the naming of "ActivityManager" that does a part of memory analysis, and also manages the Android-Activity interfaces. However, it is the LMK (low memory killer) that is really responsible for stopping processes on the basis of information provided by the ActivityManager and other System interfaces.

I found a brief analysis of this in the section "The relationship between oom_adj and upper Process Importance" at http://www.programering.com/a/MjNzADMwATE.html

Calie