What the interviewer is testing

The interviewer is checking whether you understand Android's event-driven architecture, component responsibilities, and modern background execution limits—not simply whether you know how to register a receiver.

A strong answer explains what problem a BroadcastReceiver solves, why its lifetime is deliberately short, and when the receiver should hand work to another component instead of trying to perform that work itself.

❌ Common mistake

If they ask you to elaborate

Why Android introduced BroadcastReceivers

Android needs a way to notify interested applications when important events occur without every application continuously checking for changes.

Instead of every app polling the system, Android broadcasts those events. Applications that care about them register a BroadcastReceiver and react only when the broadcast arrives.

Think of the receiver as a doorbell, not a worker. It tells the app that something happened; it should not become the place where long-running work lives.

Android event
      │
      ▼
Broadcast sent
      │
      ▼
BroadcastReceiver
      │
      ▼
Small amount of work
      │
      ▼
(optional)
WorkManager or another owner

Modern Android restricts many manifest-registered implicit broadcasts to reduce unnecessary background work and improve battery life. That makes the responsibility of the receiver even clearer: react to the event, then hand off work when necessary.

Production considerations

Keep onReceive() short and non-blocking. A receiver normally runs on the application's main thread, so blocking work can delay the app and may cause the system to terminate the receiver.

Register receivers for the smallest lifecycle that matches the requirement. If an event only matters while a screen is visible, a context-registered receiver tied to that lifecycle is usually preferable to making the receiver application-wide.

Treat incoming broadcasts as external input. Validate the action and any extras you depend on, and expose a receiver only when another application genuinely needs to reach it.

Use a BroadcastReceiver only when broadcasts are the correct communication mechanism. Modern Android APIs often provide dedicated callbacks that are more explicit and easier to scope.

Choose the right tool

The important distinction is responsibility. A BroadcastReceiver notices an event; another component should own work that needs a longer lifetime.

Code example

class BatteryReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        // Keep the receiver lightweight.
        WorkManager.getInstance(context)
            .enqueue(
                OneTimeWorkRequestBuilder<SyncWorker>().build()
            )
    }
}

The receiver reacts to the event and returns quickly. The longer-running synchronization is owned by WorkManager rather than by onReceive().

Follow-up questions

What separates a senior answer

Key takeaways

Learn more