Repository navigation
Fix voice/audio playback broken by media3 1.11.0, bump to 1.33.7 - #2237
Merged
Merged
Conversation
Voice and audio messages never played on 1.33.6; the play button spun indefinitely. AudioMediaService built its connection result from super.onConnect(), which in media3 1.11.0 returns a placeholder with no commands, so the in-app MediaController's setMediaItem, prepare and play were all dropped. Grant the default session and player commands explicitly, as 1.10.0's onConnect() did. Also log when the controller lacks playback commands, leave the loading state on a player error, and add an instrumented test that the in-app controller is granted them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contributor checklist
playflavour, bothdebugandrelease(minified, signed with the debug key)Fixes #1234syntaxDescription
Voice and audio messages don't play on 1.33.6. Tapping play shows a spinner forever. Sending still works and so does video.
Cause: #2188 bumped media3 from 1.10.0 to 1.11.0. In 1.11.0 the default
MediaSession.Callback.onConnect()returns a placeholder result with empty commands. media3 swaps in the real defaults only when that placeholder is returned unmodified.AudioMediaServicebuilt its own result fromsuper.onConnect(), soAudioPlaybackManager'sMediaControllerwas granted no player commands. ItssetMediaItem/setPlaybackSpeed/prepare/playcalls were dropped, and the only trace was a logcat warning:The bug is in the library, not R8; it reproduces in debug builds too.
Fix:
onConnectnow builds its result fromConnectionResult.DEFAULT_SESSION_COMMANDS(plus the scrub commands) andDEFAULT_PLAYER_COMMANDS. The notification controller still drops seek-to-next. This is what media3 1.10.0's defaultonConnectgranted, so behaviour matches 1.33.5. It usesConnectionResult.accept()rather thanAcceptedResultBuilder(session), which is deprecated in 1.11.0. Everything used exists in both media3 versions. media3 stays at 1.11.0.Also:
AudioPlaybackManager.play()logs a warning when the controller is missing set-media-item, prepare or play/pause, so this kind of failure shows up in exported logs, not just logcat.controllerListener.onPlayerErrorlogs the error and stops playback, so the UI leaves the loading state.AudioMediaServiceConnectionTestconnects aMediaControllerto the real service and asserts those commands are available. It fails on the code before this change and passes with it.Testing
On the emulator, before and after on the same install (the fixed build installed over the unfixed build of the 1.33.6 tag with
adb install -r, data kept), for bothdebugand minifiedrelease:MCImplBasewarnings. Play, progress, pause/resume, playback speed, scrubbing, starting a second message while one is playing (the first keeps its position and speed), and pause/play from the media notification all work.AudioMediaServiceConnectionTest: fails before the fix (COMMAND_SET_MEDIA_ITEM not available to the in-app controller), passes after.Not tested: lock-screen controls (the emulator has no screen lock; they use the same system media controls as the notification), the new
onPlayerErrorpath on a device, and upgrading from a store-signed 1.33.6 (only debug-signed builds were used).