BroadcastReceivers and Memory Usage

Question

I've not had the time to play with receivers, and also I'm unfamiliar with anything above 2.3.x, so I was totally puzzled when I read this question:
Can BroadcastReceiver registered in AndroidManifest receive intents when application process is killed?

Its author is able to see the BroadcastReceiver application in the task manager list, and when the app is killed, the broadcast receiver no longer is called. This is due to a new mechanism introduced in 3.1:
http://developer.android.com/sdk/android-3.1.html#launchcontrols

In that link, the stopped state for an Application is mentioned. Application lifecycle isn't explained anywhere in the docs, AFAIK, so I guess an App can be in one of these 3 states:

• Stopped (not in RAM)
• Started (in RAM, not running)
• Running (in RAM)

For the user to be able to see the app in the Task Manager, it should be in either started or running state (I'm guessing here, because I don't know if there are more states). And seems that the app was showing in the list for a significant amount of time. If a receiver app is started or running, it must have a linux hosting process with its own Dalvik VM instance. This is in conflict with my previous beliefs on how receivers should work:

• When a receiver isn't running, there's no performance penalty to the system.
• Once a receiver needs to be notified, a new foreground process is spawned (if not already running), a new Receiver is instantiated, and the onReceive method is called.
• After a max processing time of 10 secs, onReceive returns, and provided there are no additional Services or Activities, the hosting process is very likely being killed, thus releasing resources.

So, my questions:

1. If the app is shown in the task manager (hence there's a process), but hasn't been notified yet, why would the OS spawn a process for a receiver that hasn't even been notified (and might not be notified at all). If the app has been notified but the process hasn't been killed yet, (and so it is listed in the task manager), why doesn't the OS kill it shortly after it completes? Here I'm assuming the task manager only shows an application if it has a process allocated, but this raises the following question:
2. What are the chances of having a receiver process listed in the task manager? Does the task manager show the receiver app even if it is stopped? If so, is this the new behaviour for 3.1+ so that the user can notice it exists and force-close it? If not, the application should only be listed there if it is in the middle of a call to onReceive or after it returns and is eligible to be killed, which according to the docs, should be a short interval.

Thanks in advance.

Answer 1

so I guess an App can be in one of these 3 states: Stopped (not in RAM), Started (in RAM, not running), Running (in RAM)

Not exactly, at least as how I would phrase it, though that might be a terminology and/or language issue.

A process is either running or not running. It cannot be "in RAM" and "not running".

Independently of this concept, an application can have its manifest-registered BroadcastReceivers be disabled or enabled, as of Android 3.1. The docs refer to the disabled state as "stopped", which is a very unfortunate choice of terms on Google's part, one that I have complained about on several occasions. When you see references to this state, ignore any other definitions of the term "stopped". In fact, you might want to make up some other term for this state, such as "snicklefritzed".

Your app is snicklefritzed immediately after installation. Your app is moved into a "normal" state once something explicitly runs one of your components (e.g., user manually launches an activity from the home screen). Your app is moved back to be snicklefritzed when the user force-stops your app from Settings. The information about whether an app is normal or snicklefritzed is held in some OS-managed file and (AFAIK) is cached in an OS process.

Hence, an application is either:

• Not running (no process) and snicklefritzed
• Not running (no process) and not snicklefritzed
• Running (has a process) and not snicklefritzed

(it is not possible to be running and snicklefritzed, because the act of running something would have moved you out of the snicklefritzed state, and a force-stop would terminate your process)

When a receiver isn't running, there's no performance penalty to the system.

Correct.

Once a receiver needs to be notified, a new foreground process is spawned (if not already running), a new Receiver is instantiated, and the onReceive method is called.

Correct.

After a max processing time of 10 secs, onReceive returns, and provided there are no additional Services or Activities, the hosting process is very likely being killed, thus releasing resources.

I would phrase it as "the hosting process is eligible to be killed and will be relatively high in the priority queue to be killed as the OS needs RAM for other processes".

Why would the OS spawn a process for a receiver that hasn't even been notified (and might not be notified at all).

It doesn't. A snicklefritzed app's manifest-registered BroadcastReceivers are ignored.

What are the chances of having a receiver process listed in the task manager?

100% while the process is running. 0% when the process is not running.

Is this the new behaviour for 3.1+ so that the user can notice it exists and force-close it?

I have no idea what you are referring to when you say "this" and "it".

Or is it the normal behaviour when the system has enough memory available, even for 2.x OSes?

I still have no idea what you are referring to when you say "it".