How to Inspect Active Media Sessions and Playback Controls on Android Using ADB dumpsys media.session

Modern Android smartphones serve as primary multimedia hubs, playing music, streaming video, handling podcast queues, and managing voice call audio. To ensure a cohesive user experience across physical and virtual controls, Android decouples media playback applications (such as Spotify, YouTube Music, Pocket Casts, or local media players) from external UI surfaces using the Media Session Framework. Through this framework, background apps publish their playback state, track metadata, album artwork, and available action buttons (play, pause, skip, seek, and rewind).

The Android operating system coordinates these sessions via the MediaSessionService within system_server. When a media app is active, the framework routes lockscreen controls, notification shade media players, Bluetooth steering wheel buttons, headphone remote clicks, and Google Assistant voice commands directly to the active media session. For Android application developers, ROM builders, and automated QA testers diagnosing playback desynchronization or broken Bluetooth media controls, the Android Debug Bridge (ADB) diagnostic tool dumpsys media.session exposes the internal operational state of all active and suspended media sessions. This guide explains how the Media Session framework operates and details how to extract, interpret, and troubleshoot playback telemetry using ADB.

Architecture of the Android Media Session Framework

The Media Session architecture relies on three primary interacting components:

• MediaSession: Created by the media player app. It maintains the current PlaybackState (e.g. STATE_PLAYING, STATE_PAUSED, STATE_BUFFERING), position timestamp, playback speed, and active track metadata (artist, title, album, duration).
• MediaSessionManagerService: The central system service running inside system_server. It maintains a prioritized stack of active sessions, routes hardware media button key events (KEYCODE_MEDIA_PLAY_PAUSE, KEYCODE_MEDIA_NEXT), and enforces security boundaries across multi-user profiles.
• MediaController: Used by external surfaces (such as the System UI notification shade, Android Auto, Wear OS companion devices, or lockscreen managers) to observe metadata changes and dispatch playback commands to the active session.
• Volume and Routing Control: Media sessions can define local hardware audio stream volume handling (e.g. modifying the phone’s physical media volume) or remote volume control (for Google Cast devices or external smart speakers).

Using ADB diagnostics, developers can monitor whether media apps publish proper playback states, audit active media controllers, and verify media button routing.

Verifying ADB Connectivity and Media Service Availability

Connect your Android device or emulator via USB or wireless debugging and confirm connectivity:

adb devices -l

Confirm that the media.session service is active in the Android system server:

adb shell service list | grep -i "media\.session"

The output returns the registered Binder service:

214	media.session: [android.media.session.ISessionManager]

If present, the Media Session subsystem is operational and ready to accept diagnostic queries.

Dumping Global Media Session Service State

To inspect the complete diagnostic dump of the Media Session subsystem across all user profiles, execute the basic dumpsys command:

adb shell dumpsys media.session

The output provides a structured overview of the prioritized session stack, active controllers, and recent hardware media button dispatches:

MEDIA SESSION SERVICE (dumpsys media.session)
======================================================
User 0:
  Active Sessions (ordered by priority):
    1. Session: Spotify (com.spotify.music/10182)
       Tag: SpotifyMediaSession
       PlaybackState: state=STATE_PLAYING, position=84120ms, speed=1.0, updated=1420s ago
       Actions: 0x367 (PLAY | PAUSE | SKIP_TO_NEXT | SKIP_TO_PREV | SEEK_TO)
       Metadata:
         title: "Midnight City"
         artist: "M83"
         album: "Hurry Up, We're Dreaming"
         duration: 243000ms
       AudioAttributes: usage=USAGE_MEDIA, contentType=CONTENT_TYPE_MUSIC, stream=STREAM_MUSIC
       VolumeType: LOCAL, controlType=VOLUME_CONTROL_ABSOLUTE, max=15, current=9
       Is active: true

  Media button receiver:
    Last media button receiver: ComponentInfo{com.spotify.music/com.spotify.music.internal.receiver.MediaButtonReceiver}
    Pending intent: true

Key information revealed in this dump includes:

• Active Sessions Priority Order: Displays which app currently holds the highest priority in the media stack. Hardware media buttons (e.g. pressing play/pause on Bluetooth headphones) are delivered exclusively to the top-priority session.
• PlaybackState & Position: Confirms the exact playback state (e.g. STATE_PLAYING vs STATE_PAUSED) and millisecond position offset.
• Supported Actions Bitmask: A hexadecimal bitmask indicating which controls the app supports (e.g. seeking, skipping tracks, or fast-forwarding).
• Metadata: Displays current song title, artist, album name, and track duration currently exposed to System UI and Bluetooth AVRCP displays.
• Media Button Receiver: Details which application package will receive hardware play/pause key events when media playback is initiated while the screen is off.

Inspecting Media Session Volume and Audio Routing

When debugging volume synchronization issues between wireless Bluetooth earbuds and the Android smartphone, review the VolumeType attribute in dumpsys.

Filter dumpsys output for volume configurations:

adb shell dumpsys media.session | grep -A 6 "VolumeType"

Output illustrates volume handling characteristics:

VolumeType: LOCAL, controlType=VOLUME_CONTROL_ABSOLUTE, max=15, current=9
VolumeType: REMOTE, controlType=VOLUME_CONTROL_RELATIVE, max=100, current=45

If an app is streaming to a Chromecast target, VolumeType: REMOTE indicates that pressing the phone’s physical hardware volume rocker adjusts the remote speaker volume rather than the phone’s internal speaker.

Simulating Hardware Media Button Events via ADB

To verify whether the top-priority media session responds accurately to hardware playback controls without requiring physical button presses, dispatch key events using adb shell input keyevent:

# Simulate Play/Pause toggle
adb shell input keyevent 85

# Simulate Next Track
adb shell input keyevent 87

# Simulate Previous Track
adb shell input keyevent 88

# Simulate Stop
adb shell input keyevent 86

Immediately run dumpsys media.session after sending a key event to verify that the app updated its PlaybackState (e.g. transitioning from STATE_PLAYING to STATE_PAUSED).

Troubleshooting Common Media Session Gotchas

When media notification cards fail to appear or Bluetooth car stereos display “No Title”, review these common diagnostic indicators:

• Session Inactive (Is active: false): An app may create a MediaSession but forget to call setActive(true). When inactive, Android will not display notification controls, and Bluetooth receivers will ignore the app.
• Missing PlaybackState Actions: If lockscreen or notification skip buttons appear grayed out or missing, check the Actions bitmask in dumpsys. The app must explicitly declare ACTION_SKIP_TO_NEXT and ACTION_SKIP_TO_PREVIOUS in its PlaybackState.Builder.
• Stale Media Button Receiver: If pressing play on Bluetooth headphones unexpectedly launches an old podcast app rather than your active music player, check the Last media button receiver in dumpsys. The active media player must claim the media button receiver upon playback initiation.