Static vs. Dynamic BroadcastReceivers: Implications and Restrictions
This tests your knowledge of Android's background execution limits. A good answer defines static and dynamic registration, explains the restrictions since Android 7/8, and gives use cases. A red flag is ignoring the modern API limitations.
What's really being asked
This question assesses your understanding of fundamental Android component lifecycles and, critically, your knowledge of modern background execution limits. The interviewer wants to see if you can make informed, battery-efficient decisions. They are testing if your knowledge is current, specifically regarding the major changes introduced in Android 7.0 (Nougat) and 8.0 (Oreo).
The full answer
First, define the two types. Static receivers are declared in the AndroidManifest.xml and allow the system to launch your app, even from a killed state, to handle a broadcast. Dynamic receivers are registered in code using a Context (like an Activity or Service) and are tied to that context's lifecycle.
Second, explain the modern restrictions. Since Android 7.0 (API 24), the system no longer sends most implicit broadcasts (like CONNECTIVITY_ACTION) to manifest-declared receivers. Android 8.0 (API 26) made these restrictions even stricter. This prevents apps from waking up unnecessarily and draining the battery.
Third, provide clear use cases. Static registration is now only for a few exempt implicit broadcasts (e.g., BOOT_COMPLETED, ACTION_LOCKED_BOOT_COMPLETED) or for explicit broadcasts targeted directly at your app. Dynamic registration is for events relevant only while your app's UI is visible or a component is alive, like reacting to network changes on a specific screen.
The mistakes people make
Failing to mention the background execution limits from Android 7.0 and 8.0 is the biggest red flag. A senior candidate is expected to know this. Another common mistake is suggesting a static receiver for a restricted broadcast like CONNECTIVITY_ACTION without qualification. Forgetting to mention the need to unregister dynamic receivers (e.g., in onPause or onDestroy) is also a sign of inexperience, as it leads to memory leaks.
What usually comes next
Expect questions like: "So how would you listen for network connectivity changes in a modern app?" (The correct answer is using ConnectivityManager.registerDefaultNetworkCallback, not a BroadcastReceiver). Or, "What happens if a static receiver tries to start a Service on Android 12?" (On Android 8+, it throws an IllegalStateException; the receiver must use WorkManager or start a foreground service).
A concrete example
A correct use of a static receiver is listening for BOOT_COMPLETED to schedule a periodic task with WorkManager. A correct use of a dynamic receiver is an Activity registering a receiver in onResume() to listen for a custom ACTION_DOWNLOAD_COMPLETE broadcast sent by an internal DownloadService, and unregistering it in onPause() to stop listening when the UI is not visible.
Interview question
For an Android app to react to network connectivity changes while its UI is active, which method is recommended in modern Android versions (7.0+)?
- a.Declaring a static BroadcastReceiver in the manifest for "android.net.conn.CONNECTIVITY_CHANGE"
- b.Utilizing ConnectivityManager.registerDefaultNetworkCallback within the Activity's lifecycleCorrect
- c.Registering a dynamic BroadcastReceiver in the Activity's onResume() for "android.net.conn.CONNECTIVITY_CHANGE"
- d.Implementing a periodic check for network status using WorkManager
Why? this is the answer
The card explicitly states that for network connectivity changes in a modern app, ConnectivityManager.registerDefaultNetworkCallback is the recommended approach. While dynamic receivers are suitable for events relevant when the UI is active, for network changes specifically, Android provides a more efficient and dedicated API.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #broadcastreceiver
- #background work
- #system design
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