Introduction

For dynamically registered BroadcastReceiver instances, Android does not provide a reliable "is this receiver currently registered?" query. The normal solution is to track registration state in your own code and make registration and unregistration follow the component lifecycle predictably.

Why there is no direct check

A receiver registered with registerReceiver is attached to a particular Context and lifecycle. Android exposes the registration APIs, but not a public lookup method that answers whether a specific receiver object is currently registered.

That is why developers often run into IllegalArgumentException from unregisterReceiver: they try to unregister a receiver that is not currently registered and hope the framework will tell them first. It will not.

Track the state yourself

The simplest safe pattern is to keep a boolean flag and update it only when registration state changes successfully.

1class MainActivity : AppCompatActivity() {
2
3    private val receiver = object : BroadcastReceiver() {
4        override fun onReceive(context: Context, intent: Intent) {
5            Log.d("Receiver", "broadcast received")
6        }
7    }
8
9    private var receiverRegistered = false
10
11    override fun onStart() {
12        super.onStart()
13        if (!receiverRegistered) {
14            val filter = IntentFilter(Intent.ACTION_AIRPLANE_MODE_CHANGED)
15            registerReceiver(receiver, filter)
16            receiverRegistered = true
17        }
18    }
19
20    override fun onStop() {
21        if (receiverRegistered) {
22            unregisterReceiver(receiver)
23            receiverRegistered = false
24        }
25        super.onStop()
26    }
27}

This is usually enough. The real win is not the flag itself; it is pairing registration and unregistration with the same lifecycle owner.

Manifest-declared receivers are different

Receivers declared in AndroidManifest.xml are not dynamically registered, so the question is different. You can inspect whether the component is enabled through PackageManager, but that is not the same as checking runtime registration state.

For example:

1val component = ComponentName(this, BootReceiver::class.java)
2val state = packageManager.getComponentEnabledSetting(component)
3val enabled = state == PackageManager.COMPONENT_ENABLED_STATE_ENABLED ||
4    state == PackageManager.COMPONENT_ENABLED_STATE_DEFAULT

This only tells you whether the manifest receiver is enabled from the package manager's point of view.

Prefer lifecycle-driven registration

A lot of receiver bugs come from ad hoc registration calls scattered across button handlers, services, and fragments. A cleaner approach is to decide where the receiver should live and register it there consistently:

• 'onStart and onStop when it is tied to visible UI'
• 'onResume and onPause when it must exist only while the activity is interactive'
• a foreground service when the receiver belongs to long-running background work

Once the lifecycle is clear, the need for a separate "am I registered?" query largely disappears.

Defensive unregistration

You will sometimes see code like this:

1try {
2    unregisterReceiver(receiver)
3} catch (e: IllegalArgumentException) {
4    Log.w("Receiver", "receiver was not registered")
5}

This can be a useful last-resort guard in legacy code, but it is not the best design. It hides lifecycle mistakes instead of fixing them. Prefer explicit state tracking first.

Common Pitfalls

• Looking for a framework API that tells you whether a dynamically registered receiver is active. There is no general public method for that.
• Registering in one lifecycle callback and unregistering in a different, inconsistent one.
• Using exceptions as normal control flow instead of tracking registration state.
• Confusing manifest-declared receivers with runtime-registered receivers.
• Registering the same receiver multiple times and then assuming one unregisterReceiver call clears everything cleanly.

Summary

• Android does not provide a direct public check for whether a dynamic receiver is currently registered.
• Track registration state yourself with a flag and consistent lifecycle ownership.
• Manifest receivers are a different case; use PackageManager only to inspect component enablement.
• Use try and catch only as a defensive fallback, not as the main design.
• Clean lifecycle pairing is the most reliable way to avoid receiver registration bugs.