Static vs dynamic BroadcastReceiver registration and modern Android implications

WHAT THIS TESTS: This question probes whether you understand Android's evolving background execution model, component lifecycle boundaries, and the security and battery-life motivations behind API 26 restrictions. Interviewers want to see that you know when the system will deliver a broadcast to a non-running app versus an already-active component, and that you can reason about lifecycle leaks and exported surface area.

A GOOD ANSWER COVERS: First, static registration in the AndroidManifest creates a global entry point that survives app death and can wake your process, but since Android 8.0 (API 26) the platform blocks most implicit broadcasts from being delivered to manifest-registered receivers unless the broadcast is on the exempted system list. Second, dynamic registration inside an Activity or Service binds the receiver to that context's lifecycle; it can receive implicit broadcasts while the context is alive, but you must unregister it to prevent memory leaks and crashes. Third, explicit broadcasts targeted at your package still work with static receivers regardless of API level. Fourth, modern best practices mean you should prefer dynamic registration for UI-driven events and static registration only for specific exempted system events like BOOT_COMPLETED or package replacement where the app must restart without user interaction.

COMMON WRONG ANSWERS: Claiming that static receivers can receive any implicit broadcast on modern Android is a major red flag because API 26 explicitly limits this. Another red flag is saying dynamic receivers persist after the Activity finishes without mentioning unregistering; failing to call unregisterReceiver leads to leaks and IllegalArgumentException. A third weak pattern is conflating ordered versus normal broadcasts with the static versus dynamic distinction, which are orthogonal concepts.

LIKELY FOLLOW-UPS: The interviewer may ask how to secure a receiver, which leads to android:exported and signature-level permissions. They might ask about LocalBroadcastManager, which is deprecated and replaced with explicit intents or LiveData flows. They could also ask what happens if a foreground service registers a receiver versus an Activity, probing whether you understand that the service lifecycle extends the window but still requires cleanup.

ONE CONCRETE EXAMPLE: If you want to listen for SCREEN_ON or SCREEN_OFF, you must register dynamically in an Activity or Service because these are not exempted implicit broadcasts and will not be delivered to a manifest-registered receiver on API 26 and above. Conversely, if you need to run code after a reboot, you register statically for BOOT_COMPLETED because it is exempted and your app is not running when the device restarts.

Source: developer.android.com