3

I have an receiver which is registered in AndroidManifest, but it seems like it can't receive intents when application is killed, assume I have some misunderstanding in Android process life-cycle?

Thanks for any help.

Maheera Jazi - new account -
  • 287
  • 3
  • 12
Roman
  • 898
  • 1
  • 10
  • 24

1 Answers1

6

If the user goes into Settings and force-stops your application, on Android 3.1 and higher your BroadcastReceivers will no longer work. You are returned to the same state you are in when your app is first installed -- something must manually run a component (e.g., user launches an activity from the home screen) before your BroadcastReceivers will work again.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 3
    So, it means that if I have Incoming SMS BroadCast, it won't work if the user force-stops from settings? If yes then it seems strange. – Lalit Poptani Jul 31 '12 at 13:14
  • 1
    @LalitPoptani: "So, it means that if I have Incoming SMS BroadCast, it won't work if the user force-stops from settings?" -- first, force-stop does not stop the broadcast, it stops the receivers. Second, the user cannot force-stop their mobile carrier (e.g., AT&T) from Settings -- at most, they can force-stop an SMS client (e.g., Messenger). If they force-stop an SMS client, that SMS client will not be able to receive messages until the user manually runs the SMS client again. "If yes then it seems strange" -- you are welcome to your opinion. – CommonsWare Jul 31 '12 at 13:24
  • @CommonsWare can you ellaborate broadcast and receivers? I don't think that a BroadCastReceiver will stop working if user force-stops application from settings, because BroadCastReceiver is an event based. Correct me if I am wrong. – Lalit Poptani Jul 31 '12 at 14:02
  • @LalitPoptani: You are wrong, as of Android 3.1. http://developer.android.com/about/versions/android-3.1.html (see "Launch controls on stopped applications"). – CommonsWare Jul 31 '12 at 14:08
  • I'm surprised too. What I thought Android was supposed to do is to start a process each time it needs to run the Broadcast Receiver, then once the `onReceive` method is done, terminate the process (and in subsequent calls run again the receiver in a new different process). If this were true, and the user force-stops a process, it won't stop future calls since each call runs in a different process (provided there are no services or activities in the manifest). – Mister Smith Aug 01 '12 at 06:16
  • 1
    @MisterSmith: "then once the onReceive method is done, terminate the process" -- the process will be eligible for termination once `onReceive()` returns, but it will not just be terminated immediately in general. "it won't stop future calls since each call runs in a different process" -- force-stop is an app thing, not just a process thing. An app, once force-stopped, will never run again, until something explicitly launches a component (e.g., user runs an activity). *Centuries* could pass, and the app will still be blocked from running. – CommonsWare Aug 01 '12 at 10:32
  • @CommonsWare Javadoc for `BroadcastReceiver` says: "...if that process was only hosting the BroadcastReceiver (...), then upon returning from onReceive() the system will consider its process to be empty and aggressively kill it so that resources are available for other more important processes". – Mister Smith Aug 01 '12 at 11:25
  • @MisterSmith: That is no different than any other empty process (empty meaning having no running components). "Aggressively kill it" means "it will be towards the first in line to be killed". – CommonsWare Aug 01 '12 at 11:38
  • @CommonsWare You mean the app exists even if all processes are killed? So the broadcast receiver registration implies creating and launching an empty app, and the system launches different processes inside that app on each `onReceive` call? – Mister Smith Aug 01 '12 at 11:40
  • @MisterSmith: "You mean the app exists even if all processes are killed?" -- of course. Do you think that closing Microsoft Word uninstalls Word? I am not aware of any modern operating system that was based on the notion that an app would only ever run once, then be deleted from the system. "So the broadcast receiver registration implies creating and launching an empty app" -- not by any conventional definition of the phrase "launching an app". "and the system launches different processes inside that app on each onReceive call?" -- not by any conventional definition of "inside that app". – CommonsWare Aug 01 '12 at 11:58
  • @CommonsWare I'm totally lost here. Quoting the developer guide: "By default, every application runs in its own Linux process. Android starts the process when any of the application's components need to be executed, then shuts down the process when it's no longer needed or when the system must recover memory for other applications". Hence my confusion. However your answer makes sense (but I don't understand it) – Mister Smith Aug 01 '12 at 12:06
  • @CommonsWare More in the same page: "When the system starts a component, it starts the process for that application (if it's not already running)" Sorry for being such a pest, but what actually happens is inconsistent with what it is said in the docs. – Mister Smith Aug 01 '12 at 12:23
  • @MisterSmith: "Sorry for being such a pest, but what actually happens is inconsistent with what it is said in the docs" -- the sentence you just quoted is completely accurate. The passage you quoted in the previous comment does not contain the word "immediately" or any synonym thereof. And the so-called "stopped" state -- the state your app is in when first installed or after being force-stopped -- is stored in a file managed by the OS and is applied by the OS when that state changes. If you have further questions on the Android process model, ask a fresh SO question, please. – CommonsWare Aug 01 '12 at 12:27