So last time we looked at the life cycle of broadcast receivers and how we can register and un-register them at run time so they work perfectly for our app.  However there are some scenarios where you might want to keep your broadcast receiver running, even when app isn’t.  An example of this would be where you perhaps used your app to set up some configuration based upon a certain event.  You would often not want to even run the app but you’d still want to look out for the event regardless.  Here’s how we do this!

Broadcast receiver as a class

The first thing we’ll be doing is to move the broadcast receiver declaration into it’s own class.  We’re doing this so it’s publicly available throughout the app and can be referenced more easily from places like the manifest file which will be in step 2.

Firstly add  a new “java class” file into your project and called it something relevant. Battery_BCR for example.  You’ll have a new class file with the contents looking like the below.

package com.raptorhub.dktestbcr;

public class Battery_bcr {

Now it’s time to extend this class so that it can handle the Broadcast receiving.  Simply extend the class type and the rest should auto complete.  You can see that you should now have the same onReceive() event in the code.

package com.raptorhub.dktestbcr;

import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.util.Log;

public class Battery_bcr extends BroadcastReceiver {

    public void onReceive(Context context, Intent intent) {
        Log.i("DKi", "BCR RAN");


Now we have a broadcast receiver that we can see and implement from anywhere in the app.

Registering a static broadcast receiver using the manifest

Now we can still initiate this broadcast receiver in the exact same way as in the previous articles and it’s probably good form to write your broadcast receivers the above way anyway for good object orientation and code tidiness reasons! However then we’d have the same behaviour as before too where the receiver only works whilst the app is running.  The way we register an app for a particular broadcast message without it even needing to be run is via it’s manifest file.

Open up your apps manifest file and right after the closing tag of your last activity  you can add this bit of XML:

<receiver android:name=".Battery_bcr" android:enabled="true" android:exported="true">    
        <action android:name="android.intent.action.ACTION_POWER_CONNECTED" />

All we’ve done here is register the broadcast receiver but in a different place.  The receiver needs to know the name of the class that handles the receive, here you can see this is named “Battery_bcr” that we created above.  You then need to register the intent filter that we’re looking for, in this case we use the same ACTION_POWER_CONNECTED intent as before, and that’s it!

Registering your broadcast receiver in the manifest will make your app behave slightly differently than before.  The Android OS will now know that your app and the code you have registered to receive a message will be registered regardless of whether your app is running in the foreground, background or even if it is not running at all.

Extra points and gotcha’s

There are a few things to remember here:

  • If the intent you are looking for requires a a permission then make sure to add that in the normal manner in your manifest.  Looking for the boot_completed event, that we’ll be addressing in the next article , for example will need the uses RECEIVE_BOOT_COMPLETED permission to run.
  • Make sure you understand and test how your code will run.  Most often it will run the onReceive() event in the background and then just close down after completion but make sure you understand how this runs so you don;t get any odd app behavior.
  • You can;t easily switch this type of broadcast receiver off.  As it’s registered in the manifest statically, you cannot now switch this broadcast receiver on using code.

So there we have it, we now know how to register a broadcast receiver dynamically and statically and why we would use each method.  Whilst these work well, there are still a few loose ends and a a bit of polishing to do to wrap up a fully functioning broadcast receiver implementation and we’ll cover these of in the next blog.