Nothing plays on main since the media3 1.11.0 bump (#464): controllers get no player commands #485

Checklist

• I can reproduce the bug with the latest version given here. (Reproduced on the latest main; the 1.8.1 release itself is fine because it still uses media3 1.9.2. This is a regression on main only, present since 2026-09-01.)
• I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
• I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one bug.
• I have read and understood the contribution guidelines.

Affected app version

main at f34d4a6 (versionName 1.8.1, built from source). Any commit since d8a52cb (#464, media3 1.10.1 → 1.11.0, merged 2026-09-01) is affected; f34d4a6's parent chain before that commit is fine.

Affected Android/Custom ROM version

Android 16 (stock)

Affected device model

Motorola moto g - 2026

How did you install the app?

Built from source

Steps to reproduce the bug

1. Build main (any commit since d8a52cb) and install it.
2. Open any track, album, folder or playlist and tap a track.

Expected behavior

The track starts playing and the player screen shows its title, artist and duration.

Actual behavior

The player screen opens with an empty title and artist, 00:00 / 00:00, and nothing plays. Play/pause, next and previous do nothing. logcat shows:

W MCImplBase: Controller isn't allowed to call command= 20
W MCImplBase: Controller isn't allowed to call command= 1
W MCImplBase: Calling play() omitted due to COMMAND_PLAY_PAUSE not being available. If this play command has started the service for instance for playback resumption, this may prevent the service from being started into the foreground.
W MCImplBase: Controller isn't allowed to call command= 2

dumpsys media_session shows the app's session in state=NONE with actions=128, i.e. only the custom Close action is available.

Screenshots/Screen recordings

No response

Additional information

When it was introduced. media3 1.11.0 (released 2026-08-05) changed the default MediaSession.Callback.onConnect() in androidx/media@b0fa12d6d372 ("Change default logic of onConnect for untrusted controllers"; release notes: "Change default behavior of MediaSession.Callback.onConnect if the method is not overridden to only provide read access to untrusted controllers"). This app picked that up with #464 on 2026-09-01. The 1.8.1 release predates it.

Why it breaks here. In 1.11.0 the deprecated onConnect() default returns empty session and player command sets, tagged with an internal not-implemented marker, and MediaSessionImpl only falls back to the new onConnectAsync() when that tagged result is returned untouched. MediaSessionCallback.onConnect in this app calls super.onConnect() and rebuilds the result with ConnectionResult.accept(...), so the marker is dropped and every controller, including the app's own in-process MediaController, connects with zero player commands. media3 1.11.1 (#482) does not change this behaviour.

Fix. Build the connection result from the explicit DEFAULT_SESSION_AND_LIBRARY_COMMANDS plus the app's custom commands, and DEFAULT_PLAYER_COMMANDS, which is exactly what the pre-1.11 default handed out. One-file change, detekt clean, verified on the device above (playback resumes, no MCImplBase warnings):

QuickMythril@f561e94 (branch fix-media3-onconnect)

Happy to open a PR from that branch if you want one, or feel free to take the commit directly. I kept it to restoring the previous behaviour; if you'd rather adopt media3's new trusted/untrusted split, note that the app's own controller may not count as "trusted" by the platform check, so it would need an explicit own-package allowance.