Thursday, 6 March 2014

Android Broadcast Receivers

Broadcast Receivers simply respond to broadcast messages from other applications or from the system itself. These messages are sometime called events or intents. For example, applications can also initiate broadcasts to let other applications know that some data has been downloaded to the device and is available for them to use, so this is broadcast receiver who will intercept this communication and will initiate appropriate action.

There are following two important steps to make BroadcastReceiver works for the systen broadcasted intents:

    Creating the Broadcast Receiver.

    Registering Broadcast Receiver

There is one additional steps in case you are going to implement your custom intents then you will have to create and broadcast those intents.

Creating the Broadcast Receiver

A broadcast receiver is implemented as a subclass of BroadcastReceiver class and overriding the onReceive() method where each message is received as a Intent object parameter.

public class MyReceiver extends BroadcastReceiver {

   public void onReceive(Context context, Intent intent) {
      Toast.makeText(context, "Intent Detected.", Toast.LENGTH_LONG).show();


Registering Broadcast Receiver

An application listens for specific broadcast intents by registering a broadcast receiver in AndroidManifest.xml file. Consider we are going to register MyReceiver for system generated event ACTION_BOOT_COMPLETED which is fired by the system once the Android system has completed the boot process.

   android:theme="@style/AppTheme" >

   <receiver android:name="MyReceiver">
         <action android:name="android.intent.action.BOOT_COMPLETED">


Now whenever your Android device gets booted, it will be intercepted by BroadcastReceiver MyReceiver and implemented logic inside onReceive() will be executed.

There are several system generated events defined as final static fields in the Intent class. The following table lists a few important system events.
Event Constant    Description
android.intent.action.BATTERY_CHANGED    Sticky broadcast containing the charging state, level, and other information about the battery.
android.intent.action.BATTERY_LOW    Indicates low battery condition on the device.
android.intent.action.BATTERY_OKAY    Indicates the battery is now okay after being low.
android.intent.action.BOOT_COMPLETED    This is broadcast once, after the system has finished booting.
android.intent.action.BUG_REPORT    Show activity for reporting a bug.
android.intent.action.CALL    Perform a call to someone specified by the data.
android.intent.action.CALL_BUTTON    The user pressed the "call" button to go to the dialer or other appropriate UI for placing a call.
android.intent.action.DATE_CHANGED    The date has changed.
android.intent.action.REBOOT    Have the device reboot.
Broadcasting Custom Intents

If you want your application itself should generate and send custom intents then you will have to create and send those intents by using the sendBroadcast() method inside your activity class. If you use the sendStickyBroadcast(Intent) method, the Intent is sticky, meaning the Intent you are sending stays around after the broadcast is complete.

public void broadcastIntent(View view)
   Intent intent = new Intent();

This intent com.tutorialspoint.CUSTOM_INTENT can also be regsitered in similar way as we have regsitered system generated intent.

   android:theme="@style/AppTheme" >

   <receiver android:name="MyReceiver">
         <action android:name="com.tutorialspoint.CUSTOM_INTENT">



This example will explain you how to create BroadcastReceiver to intercept custom intent. Once you are familiar with custom intent, then you can program your application to intercept system generated intents. So let's follow the following steps to modify the Android application we created in Hello World Example chapter:
Step    Description
1    You will use Eclipse IDE to create an Android application and name it as HelloWorld under a package com.example.helloworld as explained in the Hello World Example chapter.
2    Modify main activity file to add broadcastIntent() method.
3    Create a new java file called under the package com.example.helloworld to define a BroadcastReceiver.
4    An application can handle one or more custom and system intents without any restrictions. Every indent you want to intercept must be registered in your AndroidManifest.xml file using <receiver.../> tag
5    Modify the detault content of res/layout/activity_main.xml file to include a button to broadcast intent.
6    Define a constant broadcast_intent in res/values/strings.xml file
7    Run the application to launch Android emulator and verify the result of the changes done in the aplication.

Following is the content of the modified main activity file src/com.example.helloworld/ This file can include each of the fundamental lifecycle methods. We have added broadcastIntent() method to broadcast a custom intent.

package com.example.helloworld;

import android.os.Bundle;
import android.view.Menu;
import android.content.Intent;
import android.view.View;

public class MainActivity extends Activity {

   public void onCreate(Bundle savedInstanceState) {
   public boolean onCreateOptionsMenu(Menu menu) {
      getMenuInflater().inflate(, menu);
      return true;
   // broadcast a custom intent.
   public void broadcastIntent(View view)
      Intent intent = new Intent();

Following is the content of src/com.example.helloworld/

package com.example.helloworld;

import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.widget.Toast;

public class MyReceiver extends BroadcastReceiver {

   public void onReceive(Context context, Intent intent) {
      Toast.makeText(context, "Intent Detected.", Toast.LENGTH_LONG).show();


Following will the modified content of AndroidManifest.xml file. Here we have added <service.../> tag to include our service:

<manifest xmlns:android=""
   android:versionName="1.0" >
      android:targetSdkVersion="15" />
       android:theme="@style/AppTheme" >
           android:label="@string/title_activity_main" >
               <action android:name="android.intent.action.MAIN" />
               <category android:name="android.intent.category.LAUNCHER"/>
       <receiver android:name="MyReceiver">
          <action android:name="com.tutorialspoint.CUSTOM_INTENT">

Following will be the content of res/layout/activity_main.xml file to include a button to broadcast our custom intent:

<LinearLayout xmlns:android=""
   android:orientation="vertical" >

   <Button android:id="@+id/btnStartService"


Following will be the content of res/values/strings.xml to define two new constants:


    <string name="app_name">HelloWorld</string>
    <string name="hello_world">Hello world!</string>
    <string name="menu_settings">Settings</string>
    <string name="title_activity_main">MainActivity</string>
    <string name="broadcast_intent">Broadcast Intent</string>


 For More Details

For instance, a Broadcast receiver triggers battery Low notification that you see on your mobile screen.

Other instances caused by a Broadcast Receiver are new friend notifications, new friend feeds, new message etc. on your Facebook app.

In fact, you see broadcast receivers at work all the time. Notifications like incoming messages, WiFi Activated/Deactivated message etc. are all real-time announcements of what is happening in the Android system and the applications

Consider this:

You have an important social gathering to attend. Because of your shoddy memory, you have requested your friend to notify you a day before the event. Now, because you have ‘registered’ for the said friend’s help, you will get a reminder from him as discussed. This is roughly how the Broadcast Receiver works.

We have also discussed an example at the end of this Android Tutorial (in the example, a notification is generated once the system time is changed).
How important is it to implement Broadcast Receivers correctly?

If you wish to create a good Android application, this is of utmost importance. If the broadcast events do not perform their job (of sending notifications to support the application’s primary task) perfectly, the application would not be intuitive and user friendly.
Registration of Broadcast Receiver

There are two ways to register a Broadcast Receiver; one is Static and the other Dynamic.

1)      Static: Use <receiver> tag in your Manifest file. (AndroidManifest.xml)

2)      Dynamic: Use Context.registerReceiver () method to dynamically register an instance.
Classes of Broadcasts

The two major classes of broadcasts are:

1)  Ordered Broadcasts: These broadcasts are synchronous, and therefore follow a specific order. The order is defined using android: priority attribute. The receivers with greater priority would receive the broadcast first. In case there are receivers with same priority levels, the broadcast would not follow an order. Each receiver (when it receives the broadcast) can either pass on the notification to the next one, or abort the broadcast completely. On abort, the notification would not be passed on to the receivers next in line.

2)  Normal Broadcasts: Normal broadcasts are not orderly. Therefore, the registered receivers often run all at the same time. This is very efficient, but the Receivers are unable to utilize the results.

Sometimes to avoid system overload, the system delivers the broadcasts one at a time, even in case of normal broadcasts. However, the receivers still cannot use the results.
Difference between Activity Intent and Broadcasting Intent

You must remember that Broadcasting Intents are different from the Intents used to start an Activity or a Service (discussed in previous Android Tutorials). The intent used to start an Activity makes changes to an operation the user is interacting with, so the user is aware of the process. However, in case of broadcasting intent, the operation runs completely in the background, and is therefore invisible to the user.
Implementing the Broadcast Receiver

You need to follow these steps to implement a broadcast receiver:

1)      Create a subclass of Android’s BroadcastReceiver

2)      Implement the onReceive() method: In order for the notification to be sent, an onReceive() method has to be implemented. Whenever the event for which the receiver is registered occurs, onReceive() is called. For instance, in case of battery low notification, the receiver is registered to Intent.ACTION_BATTERY_LOW event. As soon as the battery level falls below the defined level, this onReceive() method is called.

Following are the two arguments of the onReceive() method:

    Context: This is used to access additional information, or to start services or activities.
    Intent: The Intent object is used to register the receiver.


As the broadcast receivers have a global work-space, security is very important concern here. If you do not define the limitations and filters for the registered receivers, other applications can abuse them.
Here are a few limitations that might help:

    Whenever you publish a receiver in your application’s manifest, make it unavailable to external applications by using android: exported=”false”. You might think that specifying Intent filters while publishing the receiver would do the task for you, when in reality they are not enough.
    When you send a broadcast, it is possible for the external applications too to receive them. This can be prevented by specifying a few limitations.
    Similarly, when you register your receiver using registerReceiver, any application may send it broadcasts. This can be prevented using permissions as well.

(PS: As of Android 3.1, the Android system will not receive any external Intent, so the system is comparatively secure now.)

Prolonged Operations

The Broadcast Receiver object is active only for the duration of onReceive (Context, Intent).
Therefore, if you need to allow an action after receiving the notification services should be triggered, and not broadcast receivers.

    To show a dialogue, then you should use NotificationManager API
    If you wish to send a broadcast intent that would stick around even after the broadcast is complete, you must use sendStickyBroadcast (Intent) method.

Broadcast Receiver Example

In this sample application, a notification is generated when you change the system time. The notification when clicked leads the user to the Contacts. This is how the application works:


 We have seen Activities and Intents. Now we need to move on to services. However, since services mostly interact with a user through notifications, I felt the need to introduce a simple program to deal with Notifications.

What are Notifications? The name itself implies their functionality. They are a way of alerting a user about an event that he needs to be informed about or even take some action on getting that information.

Notification on Android can be done in any of the following ways:

    ·         Status Bar Notification
    ·         Vibrate
    ·         Flash lights
    ·         Play a sound

From the Notification, you can allow the user to launch a new activity as well. Now we will look at status bar notification as this can be easily tested on the emulator.

To create a status bar notification, you will need to use two classes: Notification and NotificationManager.

    ·         Notification – defines the properties of the status bar notification like the icon to display, the test to display when the notification first appears on the status bar and the time to display.
    ·         NotificationManager is an android system service that executes and manages all notifications. Hence you cannot create an instance of the NotificationManager but you can retrieve a reference to it by calling the getSystemService() method.

Once you procure this handle, you invoke the notify() method on it by passing the notification object created.

So far, you have all the information to display on the status bar. However, when the user clicks the notification icon on the status bar, what detailed information should you show the user? This is yet to be created. This is done by calling the method setLatestEventInfo() on the notification object. What needs to be passed to this method, we will see with an example.

You can download the code for a very simple Notification example here:

The code is explained below:

Step 1: Procure a handle to the NotificationManager:

            private NotificationManager mNotificationManager;
mNotificationManager =

Step 2: Create a notification object along with properties to display on the status bar

final Notification notifyDetails =
new Notification(,"New Alert, Click Me!",System.currentTimeMillis());

Step 3: Add the details that need to get displayed when the user clicks on the notification. In this case, I have created an intent to invoke the browser to show the website

Context context = getApplicationContext();
CharSequence contentTitle = "Notification Details...";
CharSequence contentText = "Browse Android Official Site by clicking me";
Intent notifyIntent = new Intent(android.content.Intent.ACTION_VIEW,Uri.parse(""));
PendingIntent intent =
      PendingIntent.getActivity(SimpleNotification.this, 0,
      notifyIntent, android.content.Intent.FLAG_ACTIVITY_NEW_TASK);
notifyDetails.setLatestEventInfo(context, contentTitle, contentText, intent);
Step 4: Now the stage is set. Notify.
      mNotificationManager.notify(SIMPLE_NOTFICATION_ID, notifyDetails);

Note that all of the above actions(except getting a handle to the NotificationManager) are done on the click of a button “Start Notification”. So all the details go into the setOnClickListener() method of the button.
Similarly, the notification, for the example sake is stopped by clicking a cancel notification button. And the code there is :

Now, you may realize that the constant SIMPLE_NOTIFICATION_ID becomes the way of controlling, updating, stopping a current notification that is started with the same ID.

For more options like canceling the notification once the user clicks on the notification or to ensure that it does not get cleared on clicking the “Clear notifications” button, please see the android reference documentation.

Activity Life Cycle and version history

1) Starting State:

When an activity does not yet exist in memory, it is in the starting state.
2) Resumed/Running State:

An activity that is in the foreground is in the running state. Any activity that is currently on the screen and interacting with the user is the running activity at that particular point in time. It exists at the top of the Activity stack.
3) Paused State:

When an activity is not in focus (i.e. not interacting with the user), but is still visible on the screen, it is in the Paused state.
4) Stopped State:

An activity that is not visible on the screen, but exists in the memory is in the Stopped State.
5) Destroyed State:

A Destroyed activity results from the removal of an activity (that is no longer required) from the memory. Such removals generally occur, when the activity manager decides that there is no use for such activities anymore.

 version history

Android 1.0 (API level 1)
Android 1.1 (API level 2)
Android 1.5 Cupcake (API level 3)
Android 1.6 Donut (API level 4)
Android 2.0 Eclair (API level 5)
Android 2.0.1 Eclair (API level 6)
Android 2.1 Eclair (API level 7)
Android 2.2–2.2.3 Froyo (API level 8)
Android 2.3–2.3.2 Gingerbread (API level 9)
Android 2.3.3–2.3.7 Gingerbread (API level 10)
Android 3.0 Honeycomb (API level 11)
Android 3.1 Honeycomb (API level 12)
Android 3.2 Honeycomb (API level 13)
Android 4.0–4.0.2 Ice Cream Sandwich (API level 14)
Android 4.0.3–4.0.4 Ice Cream Sandwich (API level 15)
Android 4.1 Jelly Bean (API level 16)
Android 4.2 Jelly Bean (API level 17)
Android 4.3 Jelly Bean (API level 18)
Android 4.4 KitKat (API level 19)