How to Inspect System Broadcast Dispatch Queues on Android Using ADB dumpsys activity broadcast-stats

In the Android operating system, inter-application communication and system event notifications—such as network connectivity changes, battery level alerts, package installations, and time zone updates—are delivered via Broadcast Intents. The ActivityManagerService (AMS) coordinates broadcast dispatch through dedicated foreground and background queues. When background applications execute blocking operations inside their onReceive() callbacks or flood the system with frequent broadcast dispatches, system responsiveness degrades, resulting in input latency and Application Not Responding (ANR) dialogs. Android Debug Bridge (ADB) exposes historical and real-time dispatch telemetry through dumpsys activity broadcast-stats, enabling developers to pinpoint broadcast bottlenecks.

Android Broadcast Dispatch Queue Architecture

The Android framework manages broadcast delivery using prioritized execution pipelines:

• Foreground Broadcast Queue: Reserved for high-priority, time-sensitive system events. Handlers have strict delivery timeout budgets (typically 10 to 20 seconds) before an ANR is declared.
• Background Broadcast Queue: Used for general non-interactive broadcasts (such as battery stats updates or cloud sync notifications). Delays in the background queue will not freeze the foreground user interface, but excessive queues consume CPU cycles and drain battery.
• Ordered vs Normal Broadcasts: Normal broadcasts are dispatched to registered receivers in parallel. Ordered broadcasts are executed sequentially, one receiver at a time, allowing handlers to abort the broadcast or modify results before passing them downstream.

Dumping Broadcast Telemetry via ADB

To inspect cumulative broadcast dispatch metrics across all applications, execute the diagnostic command via ADB:

# Dump system-wide broadcast dispatch statistics
adb shell dumpsys activity broadcast-stats

The output aggregates dispatch metrics by Intent action and target package:

Broadcast stats:
  Action: android.net.conn.CONNECTIVITY_CHANGE
    Count: 412
    Total dispatch time: +3m42s819ms
    Max dispatch time: +1s420ms
    Package: com.example.analytics (Count: 140, Total time: +1m12s310ms)
    Package: com.google.android.gms (Count: 272, Total time: +2m30s509ms)

Evaluating Key Performance Metrics in broadcast-stats

Auditing the broadcast statistics output highlights application performance regressions:

• Count: The total number of times an Intent action was triggered or delivered to a specific application package since system boot.
• Total Dispatch Time: Cumulative CPU execution time spent by all receiver components processing that specific broadcast action.
• Max Dispatch Time: The single longest time an individual receiver spent executing inside onReceive(). If this value approaches 5 to 10 seconds, the application risks triggering an ANR.
• Wakeup Count: The number of times the broadcast woke the application process from an idle or cached background state, requiring process spawning and Dalvik/ART virtual machine initialization.

Inspecting Live Broadcast Queues and Congestion

While broadcast-stats provides historical metrics, inspecting active pending queues reveals current queue depth and blocking handlers:

# Inspect currently enqueued and pending broadcasts
adb shell dumpsys activity broadcasts | grep -A 25 "Pending Broadcasts"

If the background or foreground queue shows dozens of unhandled entries with a stagnant timestamp, the head-of-line receiver is deadlocked on a synchronous network call or database query.

Filtering Broadcast Metrics for Specific Application Packages

To audit how your specific application behaves under system load without parsing thousands of lines of system server logs:

# Filter broadcast statistics for a specific application package
adb shell dumpsys activity broadcast-stats | grep -B 2 -A 10 "com.example.myapp"

This reveals which system broadcasts invoke your receivers most frequently, allowing you to transition expensive receivers to modern Android JobScheduler or WorkManager APIs.

Resetting Broadcast Statistics During Profiling

To benchmark performance before and after code optimizations, clear the cumulative statistics buffer without rebooting the physical device:

# Clear and reset all broadcast statistics counters
adb shell cmd activity broadcast-stats --reset

Trigger a specific workflow in your application, then re-run adb shell dumpsys activity broadcast-stats to capture isolated metrics for that exact test cycle.

Best Practices to Eliminate Broadcast Latency Bottlenecks

To prevent applications from appearing at the top of broadcast-stats resource consumption reports:

• Avoid Blocking inside onReceive(): Never perform disk I/O, heavy JSON parsing, or network calls inside the main receiver thread; delegate heavy operations to goAsync() or WorkManager.
• Replace Implicit Broadcasts: On modern Android versions (Android 8.0+), avoid registering implicit broadcast receivers in the manifest; rely on dynamic context-registered receivers tied to the activity lifecycle.
• Use LocalBroadcastManager: For communication entirely internal to your application process, use in-process event buses or Kotlin Flows rather than dispatching Intents through the system server.