Broadcast Receiver Android: what it is, why you need it and how it works

In the ecosystem Android there is a fundamental mechanism that allows applications to exchange messages and respond to system events. This component is called Broadcast Receiver. In simple terms, this is the “radio receiver” of your smartphone, which constantly listens to the airwaves in anticipation of certain signals.

Without this tool, the mobile operating system would turn into a set of isolated apps unable to coordinate actions. For example, when you connect the charger, the system sends a message about this event. An application that displays a battery charging animation uses exactly Broadcast Receiverto “hear” this signal and start the desired process.

Understanding how they work broadcast receiver androidis critical not only for developers, but also for advanced users. This knowledge helps you understand why some apps start on their own, how to optimize power consumption, and what permissions are really needed for the software to work.

Architectural role of a component in the system

A component BroadcastReceiver is one of the four main building blocks of an application along with Activity, Service and ContentProvider. Its main task is to respond to broadcast messages, which can come from both the system and other applications. Unlike the user interface, this component does not have a visual representation.

When an important event occurs, the Android system creates an object Intentthat contains all the necessary information about what happened. This_intent_ is sent to all registered recipients. The working mechanism is designed in such a way that the sender of the message does not need to know who exactly will receive it. This ensures loose coupling of system components.

There are two main ways to register a message recipient. The first is static registration in the manifest file AndroidManifest.xml. In this case, the application will be able to receive messages even if it is not currently running. The second method is dynamic registration directly in the application code while it is running.

⚠️ Attention: Starting with Android 8.0 (Oreo), Google has introduced strict restrictions on background work. Applications can no longer register most implicit broadcasts in the manifest if they are in the background. This was done to save battery.

Dynamic registration is valid only while the context in which it was called is active (for example, while the Activity is open). As soon as the user minimizes the application or closes the screen, such a receiver stops functioning unless special services are used.

Types of broadcast messages

All messages in the system can be divided into several categories depending on their source and scope. Understanding this classification helps determine how critical a particular event is for the operation of the device.

System messages are generated by the operating system itself Android. They cover changes in the state of the equipment or network. For example, completing the system boot, changing the volume level, or switching the interface language.

• 🔋 ACTION_BATTERY_LOW — notification of low battery charge.
• 📶 ACTION_WIFI_STATE_CHANGED — changing the state of the Wi-Fi connection.
• 🔌 ACTION_POWER_CONNECTED — the device is connected to a power source.
• 📷 ACTION_HEADSET_PLUG — connecting or disconnecting a wired headsets.

In addition to system events, there are messages generated by the applications themselves. Developers can create their own Custom Broadcasts for internal communication between different modules of the same app or for interaction with other installed applications.

There is also a division into normal and ordered broadcasts. Regular messages are delivered to all registered recipients asynchronously and in parallel. Ordered ones are delivered sequentially, one after the other, which allows one application to intercept the message and prevent its further transmission.

Implementation and registration in code

To create your own message receiver, you need to create a class that inherits from the base class BroadcastReceiver. Inside this class, you need to override the only required method onReceive(). It is in this method that the logic for reacting to the received event is written.

public class MyReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
// Event processing logic
String action = intent.getAction();
if (Intent.ACTION_BOOT_COMPLETED.equals(action)) {
// Actions after loading the system
}
}
}

After creating the class, it needs to be registered. When registering statically, a corresponding tag indicating the action filter (intent-filter) is added to the file. This allows the system to know exactly which events your application is subscribed to. AndroidManifest.xml a corresponding tag is added indicating the action filter (intent-filter). This allows the system to know exactly what events your application is subscribed to.

Dynamic registration is performed in Java or Kotlin code using the registerReceiver()method. This is usually done in the activity method, and unsubscribe (unregister) in the activity method. This approach provides flexibility, but requires careful management of the lifecycle to avoid memory leaks. onCreate() activity, and unsubscribe (unregister) - in the method onDestroy(). This approach provides flexibility, but requires careful lifecycle management to avoid memory leaks.

Registration type	Where it is specified	Working in the background	Lifecycle
Static	AndroidManifest.xml	Yes (with restrictions)	Entire installation period
Dynamic	Application code (Java/Kotlin)	No (active only application)	While the context is active
Local	LocalBroadcastManager	Only within the application	Depends on the component

It is important to note that the method onReceive() is executed in the main application thread. This means that it cannot perform long operations, such as downloading data from the network or complex calculations. If the process takes more than 10 seconds, the system will forcefully terminate the application, considering it hung (ANR).

Security and protection from abuse

The broadcast mechanism has historically been a vector for various attacks and unwanted application behavior. Attackers could intercept sensitive data or run processes without the user's knowledge. Therefore, modern versions Android have implemented strict security measures.

One ​​of the key measures is the use of explicit intents instead of implicit ones. Explicit Internet identifies a specific recipient by class or package name, which eliminates the possibility of a third-party application intercepting the message. For internal communications within one application, this is a mandatory practice.

⚠️ Attention: Never transmit sensitive data (passwords, tokens, personal information) through regular broadcast messages. Any application with the appropriate rights can intercept such Internet and read its contents.

There is also a signature permissions mechanism. A developer can secure his mailing by requiring that the receiving application be signed with the same certificate as the sender. This ensures that the message will only be received by trusted software from the same manufacturer.

Starting with Android 12, additional restrictions have been introduced on launching activities from background processes via broadcast. This prevents a situation where an application suddenly opens a window on top of other apps without user interaction, which was often used in adware.

What is a Pending Intent?

A Pending Intent is a wrapper object that allows another application to perform an action on your behalf with your rights. This is often used in widgets and notifications, but requires care when transferring access rights.

Impact on battery life and performance

Excessive use Broadcast Receiver is one of the common reasons for rapid battery drain. When an application registers for many system events, it is forced to constantly "wake up" even in sleep mode to check if anything important has happened.

Every time the processor wakes up to process even a short message, it consumes energy. If there are hundreds of such messages per minute (for example, when the network status changes in an area of ​​poor coverage), the device can heat up and the charge melts before our eyes.

• 📉 Wake Locks — some receivers keep the processor active, preventing it from going to sleep.
• 🔄 Cycle — the constant cycle of registration and sending increases the load on the task scheduler.
• 🚫 Background limits — the system can forcefully stop the application too often using a background.

Modern development approaches suggest using WorkManager or JobScheduler instead of classic receivers for deferred tasks. These tools allow the system to combine tasks from different applications and execute them at the optimal time, minimizing the number of times the device wakes up.

Users can check which apps are using the most background processes in the Battery section of settings. If you see a app that you rarely use, but it consumes a lot of energy in the background, it is worth checking its permissions to receive system events.

Diagnostics and debugging of events

For developers and enthusiasts, there is a set of tools that allowing you to monitor the flow of broadcast messages in real time. The main tool is adb (Android Debug Bridge) connected to the computer.

Using the command dumpsys you can get detailed information about registered recipients in the system. This helps identify applications that have subscribed to events but are not working correctly, or find hidden processes.

adb shell dumpsys activity receivers

It is also useful to use commands to force test messages to be sent. This allows you to check whether your application responds to certain events without waiting for them to actually occur in the system.

Not all messages visible in the log are critical. Many of them are service information generated by internal system components for debugging.

⚠️ Attention: Settings interfaces and menu item names may differ depending on the version of Android and the manufacturer's shell (MIUI, OneUI, ColorOS). Always check the latest documentation for your specific device model.

Frequently asked questions (FAQ)

Is it possible to completely disable Broadcast Receiver for a specific application?

It is not possible to completely disable the mechanism at the system level for an individual application without root access, since it is part of the architecture. However, you can prevent an application from auto-starting and running in the background through the battery settings, which effectively blocks the receipt of most background messages.

Why does the application launch itself after the phone is rebooted?

This is classic behavior for applications that use a system event. BOOT_COMPLETED. Developers are adding this feature so that messengers can receive notifications and alarms can ring at a set time immediately after turning on the phone.

Is it safe to give permissions to “Receive SMS” or “Calls”?

These permissions are often related to the processing of the corresponding broadcast events. They should only be provided to trusted applications (for example, banking or official clients of operators), since through them you can intercept confirmation codes or information about incoming calls.

Does a large number of installed applications affect the speed of Broadcast?

Yes, it does indirectly. The more applications register for the same system events (for example, network changes), the longer the system takes to deliver the message to each recipient. This can create micro-delays in the operation of the interface.

What is LocalBroadcastManager and is it needed now?

Previously, this class was used to send messages only within one application. It is now deprecated. Google recommends using other architectural components, such as LiveData or Flow, which integrate more securely and efficiently with the application lifecycle.