Static vs dynamic BroadcastReceiver registration and modern Android implications
Tests background limits, lifecycle coupling. Static manifest receivers survive app death but API 26 blocks most implicit broadcasts; dynamic receivers run with the context and must be unregistered. Red flag: static registration handles all implicit broadcasts.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
Which statement accurately describes a key difference between static and dynamic BroadcastReceiver registration on Android 8.0+ (API 26)?
- a.Static receivers can receive any implicit broadcast even if the app is not running, while dynamic receivers require the app process to be active.
- b.Static receivers survive app death but are blocked from most implicit broadcasts unless exempted, while dynamic receivers tied to a context can receive implicit broadcasts but must be unregistered.Correct
- c.Explicit broadcasts are blocked for static receivers on API 26+, so they must always be registered dynamically to receive intra-app messages.
- d.Dynamic receivers continue receiving broadcasts after their context is destroyed until the system kills the process, while static receivers must be unregistered to avoid leaks.
Why? this is the answer
This is correct because API 26 restricts most implicit broadcasts from reaching manifest-registered receivers unless exempted (e.g., BOOT_COMPLETED), whereas dynamic receivers can still receive implicit broadcasts while their context is alive but must be unregistered to prevent leaks. Option A is tempting but wrong because it ignores the API 26 restriction that blocks most implicit broadcasts from static receivers.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #broadcastreceiver
- #background-execution
- #api-26
- #lifecycle
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles