Broadcast Receiver: Responding to System-Wide Events

WHY IT EXISTS: Apps often need to react to events happening outside their own UI, even when they aren't running in the foreground. Android needed a mechanism to deliver these system-wide notifications, like "battery is low" or "network connected," to any interested app without requiring the app to be constantly running and polling for changes.

THE MENTAL MODEL: Think of a Broadcast Receiver as an antenna tuned to specific frequencies, which are called "intent filters." When the Android system or another app sends out a broadcast message (an Intent) on a frequency you're listening to, your receiver wakes up, processes the message, and then goes back to sleep. It's a passive listener, not an active, long-running process.

HOW IT WORKS: You create a class that extends BroadcastReceiver and implement the onReceive() method, which is where your logic goes. You then register your receiver in one of two ways. First, statically in your AndroidManifest.xml to listen for events even when your app is closed (though modern Android versions heavily restrict this). Second, dynamically in your code (e.g., in an Activity or Service) to listen only while that component is alive. When a matching broadcast Intent is sent, the system calls your onReceive() method on the main thread.

WHEN TO USE IT: Use it for reacting to infrequent but important system events. Three common places this shows up: first, listening for ACTION_BOOT_COMPLETED to schedule tasks after a reboot; second, listening for CONNECTIVITY_ACTION to know when network status changes; third, receiving push notifications from services like Firebase Cloud Messaging (FCM).

WHEN NOT TO USE IT: Do not use a Broadcast Receiver for any long-running or heavy processing. The onReceive() method runs on the main thread and has a very short execution window (around 10 seconds) before the system may kill it. For any real background work, the receiver's only job should be to trigger a WorkManager task or start a foreground service. For frequent communication within your own app, consider using LiveData or Kotlin Flows instead of local broadcasts for better performance.

ONE CANONICAL EXAMPLE: A common use case is an app that needs to sync data when the device connects to an unmetered network. The app would register a receiver for the android.net.conn.CONNECTIVITY_CHANGE action. When the user connects to Wi-Fi, the system broadcasts this intent. The receiver's onReceive() method is called, checks if the new connection is unmetered, and if so, schedules a sync job using WorkManager.