Static vs. Dynamic BroadcastReceivers: Implications & Restrictions

What's really being asked

This question probes your understanding of Android's evolution towards stricter battery and resource management. The interviewer isn't just looking for definitions; they are testing if you write modern, efficient code. They want to see if you know the critical background execution restrictions introduced in Android 7.0 (Nougat) and solidified in Android 8.0 (Oreo), and can explain the 'why' behind them.

The full answer

First, the core definition: Static receivers are declared in the AndroidManifest.xml and can launch an app process to respond to a broadcast. Dynamic receivers are registered in code using a Context (like an Activity or Service) and are bound to that context's lifecycle.

Second, the lifecycle difference: A dynamic receiver is only active while its registering component is. For an Activity, this is typically between onResume and onPause. A static receiver, in theory, is always active after app installation.

Third, the critical restriction: For apps targeting Android 8.0 (API 26) or higher, the system imposes significant restrictions on manifest-declared receivers. Most implicit broadcasts (system-wide events not targeted at your app) will no longer be delivered to them. This is the key point.

Fourth, modern use cases and exceptions: Mention that explicit broadcasts (sent directly to your app's package) are still fine for static receivers. Also, name a few protected implicit broadcasts that are still delivered, such as ACTION_BOOT_COMPLETED. The modern pattern is to use dynamic receivers for UI-related events and WorkManager for most deferred background work.

The mistakes people make

Giving a textbook definition of static vs. dynamic without mentioning the API 26+ restrictions. This answer is nearly a decade out of date and a major red flag.

Incorrectly stating that static receivers are completely deprecated or that all implicit broadcasts are blocked. Nuance is key; knowing the exceptions like BOOT_COMPLETED is a senior-level signal.

Failing to connect the restrictions to the reason: battery life and system health. Senior engineers understand the user-impact of technical decisions.

Suggesting a static receiver for a common but now-restricted broadcast like CONNECTIVITY_ACTION without qualifying that this no longer works on modern Android.

What usually comes next

"If you can't use a static receiver for network changes, what should you use to schedule work for when the network is available?" (Correct answer: WorkManager with a NetworkType constraint.)

"What is an explicit broadcast and why are they exempt from these restrictions?" (Answer: It targets a specific app component, so the system knows the sender's intent is deliberate, not an opportunistic system-wide event.)

"What happens if a user force-stops your app?" (Answer: The app is put into a stopped state and will not receive any broadcasts, including static ones for BOOT_COMPLETED, until the user manually launches it again.)

A concrete example

A permitted static receiver use case is registering for ACTION_BOOT_COMPLETED in the manifest to schedule recurring tasks with WorkManager after a device reboot. A dynamic receiver is perfect for an Activity that needs to listen for a local broadcast, like ACTION_DOWNLOAD_COMPLETE, to update the UI. You would register it in onResume and unregister it in onPause to prevent memory leaks and ensure it only runs when the UI is visible.