Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

MediaSessionService: the platform session keeps every player command and publishes the whole queue until the session is added, e.g. after a sticky restart

Open
  • Is something wrong?
#3,490 3 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 4 days

@marcbaechinger is already working on this.

Since Oct 26, 2026.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
android, java
Domain
backend, mobile

Research direction

Start by tracing MediaSessionService.onCreate(), onStartCommand() and addSession(), then follow how MediaNotificationManager connects its controller and how the platform session receives player commands. Reproduce the sticky restart and inspect dumpsys media_session; done means the platform session respects the notification controller's command restriction from startup and resumed playback runs with the media notification and foreground service.

Written by the indexing model from the issue text.

Description

bug
Version

Media3 pre-release (alpha, beta or RC not in this list)

More version details

Media3 1.12.0-alpha01. Also reproduced with 1.11.1.

Devices that reproduce the issue
  • Android emulator, API 30 (Android 11). Not tried on other devices; nothing in the path described below depends on the API level.
Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Not tested

Reproduction steps

The documented pattern builds the MediaSession in MediaSessionService.onCreate() and returns it from onGetSession(). The platform session takes its commands from the media notification controller, so removing Player.COMMAND_GET_TIMELINE from that controller in MediaSession.Callback.onConnect keeps the queue out of the platform session (1.2.0 release notes).

That restriction only takes effect once MediaSessionService.addSession() has run, because only then does MediaNotificationManager connect the notification controller. Until then the legacy stub keeps DEFAULT_PLAYER_COMMANDS. When the system restarts a sticky service after its process was killed while playing, onStartCommand(null) returns START_STICKY without adding the session, while the platform session is already active. The next headset key then reaches the platform session directly, onPlaybackResumption restores the queue, and the platform session publishes it.

  1. A MediaSessionService that builds its session in onCreate, removes COMMAND_GET_TIMELINE from the media notification controller in onConnect, and restores a queue in onPlaybackResumption.
  2. Play, then adb shell kill -9 <pid> while playing. The system schedules a restart of the crashed service.
  3. Once it has restarted, adb shell input keyevent KEYCODE_MEDIA_PLAY.
  4. adb shell dumpsys media_session
Expected result

The platform session follows the media notification controller's commands from the start, so it never holds the queue, and playback resumed this way runs in the foreground under the media notification.

Calling addSession(session) in onCreate, right after building the session, works around it: https://github.com/LordDetson/piplayer/commit/f502ab7

Actual result
  • The platform session publishes the whole queue (dumpsys media_session shows its size) until any Media3 controller connects; opening the app's activity clears it. With a large queue that is every item on every timeline change.
  • Playback runs without the media notification and without the foreground service.
  • On Android 11 the queue appearing and disappearing again also hits a race in the Bluetooth AVRCP service: MediaPlayerWrapper.isMetadataSynced calls getQueue() twice, and com.android.bluetooth crashed once with a NullPointerException in our runs (fixed in Android 12 by "AVRCP: Cache queue in isMetadataSynced").

Related: #459 (START_STICKY restarts).

Media

Not applicable. An instrumented test that reproduces the state without killing the process (a binding that Media3 does not serve creates the service without addSession): https://github.com/LordDetson/piplayer/blob/main/app/src/androidTest/kotlin/io/github/lorddetson/piplayer/playback/PlatformQueueTest.kt

Bug Report
  • You will email the zip file produced by adb bugreport to [email protected] after filing this issue.
Dominant language
Java
Stars
3.1k
Forks
998
Avg merge
6d 8h
Merged PRs (30d)
2

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from androidx/media

All issues in androidx/media

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.