22

I am trying to understand the main differences between registering a BroadcastReceiver in the Manifest and registering it programmatically...

My understanding is basically as follows (would appreciate someone correcting my points if I am missing something).

  • Registered in Manifest:

    1. The OS will magically find and instantiate your class if needed, calling the onReceive() method, regardless what the running state of your application was
    2. Your receive will only get called once per broadcast (i.e. You can consider that registering in the manifest is like registering your 'class' for receiving the broadcast - and the broadcast instantiates your class as needed) (??)

  • Registered Programmatically:

    1. registering in code means that you are registering instances of your class to receive broadcast messages (i.e. if your code is a little sloppy, and you manage to register several times, you will end up with multiple BroadcastReceiver instances all having their onReceive() called for a broadcast
    2. to unregister, you need to unregister the specific BroadcastReceiver instance that you previously registered
    3. if your application gets destroyed by the OS, your onReceive() method will not be called for a broadcast

thanks

Behzad Bahmanyar
  • 6,195
  • 4
  • 35
  • 41
rwm
  • 241
  • 2
  • 4

3 Answers3

21

You have it basically correct.

Note that a manifest-registered receiver object is only used once. A new instance of your BroadcastReceiver is created for each broadcast. The primary use of manifest-registered receivers is for broadcasts that may go on while your code is not in memory (e.g., BOOT_COMPLETED, your scheduled alarms via AlarmManager).

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • And I guess that if your service crashes where your broadcastreceiver is declared in the manifest, the receiver will still receive the messages... – Boy Sep 17 '12 at 09:28
  • please can you look up if that related to my problem : http://stackoverflow.com/questions/29728000/wifi-changed-status-affecting-my-app – Muhammed Refaat Apr 19 '15 at 10:17
  • Does that mean when an app have BroadcastReceiver registered in manifest, the process is always running on background? – Behzad Bahmanyar Mar 29 '16 at 14:36
  • 3
    @BehzadBahmanyar: No. It means that Android itself maintains a catalog of registered receivers. When a matching broadcast is encountered for a manifest-registered receiver, if there is no process already running, Android will start up a process for you. – CommonsWare Mar 29 '16 at 14:44
  • Thanks for nice answer. but is there any official doc to support this statement? – Behzad Bahmanyar Mar 29 '16 at 15:03
  • Clear and clean answer but @CommonsWare can you provide the references to support the statement? – Saad Bilal Jun 04 '16 at 10:50
  • @SaadBilal: https://developer.android.com/reference/android/content/BroadcastReceiver.html#ReceiverLifecycle – CommonsWare Jun 04 '16 at 11:31
  • @CommonsWare Thank you. let me review – Saad Bilal Jun 10 '16 at 11:31
5

When to use which method to register

Which method to use for registering your BroadcastReceiver depends on what your app does with the system event. I think there are basically two reasons why your app wants to know about system-wide events:

  1. Your app offers some kind of service around these events

  2. Your app wants to react graciously to state changes

Examples for the first category are apps that need to work as soon as the device is booted or that must start some kind of work whenever an app is installed. Battery Widget Pro or App2SD are good examples for these kinds of apps. For this type you must register the BroadcastReceiver in the Manifest file.

Examples for the second category are events that signal a change to circumstances your app might rely on. Say your app depends on an established Bluetooth connection. You have to react to a state change – but only when your app is active. In this case there is no need for a statically registered broadcast receiver. A dynamically registered one would be more reasonable.

There are also a few events that you are not even allowed to statically register for. An example for this is the Intent.ACTION_TIME_TICK event which is broadcast every minute. Which is a wise decision because a static receiver would unnecessarily drain the battery.

Sunil Kumar Sahoo
  • 53,011
  • 55
  • 178
  • 243
0

Your understanding is correct according to mine.

Another relevant (and obscure) difference is that some specific system Intents will only trigger your receiver if it's programmatically registered. Receivers only defined in the manifest won't be called. Examples are: ACTION_SCREEN_ON, ACTION_SCREEN_OFF, ACTION_BATTERY_CHANGED, ACTION_HEADSET_PLUG

I'd recommend this text that mentions various details about Intents and Receivers.

Community
  • 1
  • 1
Victor Basso
  • 5,556
  • 5
  • 42
  • 60
  • Well i managed to register a reciever for ACTION_SCREEN_ON via the manifest and it works – Jono Jun 08 '16 at 10:32