MediaPlayer small audio drop outs playing MP3/AAC http streams on Google Pixel devices [394350446]

Assigned

Bug

[AOSP] assigned

Status Update

No update yet.

Description

pu...@gmail.com

created issue #1

Feb 5, 2025 09:52AM

I'm the developer of an app that plays MP3/AAC http streams. It uses MediaPlayer, playing a http URL pointing to a MP3/AAC stream. Nothing special here.

Since a while, only on Google Pixel devices (starting at least at Pixel 6 up to Pixel 9, with various Android versions up to the latest stable Android 15), there is a buffering issue resulting in periodic small audio drop out, every time MediaPlayer does buffering.

Each time there is a drop out, logcat shows:

MediaPlayerNative  W   58:41.459  info/warning (703, 0)
                         W   58:41.460  info/warning (701, 0)
                         W   58:41.483  info/warning (703, 0)
                         W   58:41.483  info/warning (702, 0)

code 701 is MEDIA_INFO_BUFFERING_START whose documentation in mediaplayer.h says:

// MediaPlayer is temporarily pausing playback internally in order to
// buffer more data.
MEDIA_INFO_BUFFERING_START = 701,

So audio is briefly pausing until code 702 (MEDIA_INFO_BUFFERING_END) is received 23ms, enough for the drop out to be heard.

It would be really great to see this buffering issue fixed because it only happens on Google Pixel devices (to my knowledge). In my app I have a workaround that replaces MediaPlayer by FFmpeg for the decoding, but not all apps will have that luxury.

To reproduce it on a Google Pixel:

initialize a MediaPlayer instance to play a MP3 or AAC http stream (MediaPlayer#setDataSource)
as music is playing, observe small audio drop outs every 20-30s as MediaPlayer is buffering, with related traces in logcat

Comments

fr...@gmx.de <fr...@gmx.de> #2Feb 5, 2025 11:52AM

Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.

vi...@google.com <vi...@google.com> #3Feb 5, 2025 02:38PM

Assigned to vi...@google.com.

One more detail, Data Layer event calls from the watch to the phone (running Android 13) do work on if the listener is in an Activity or Fragment.

pu...@gmail.com <pu...@gmail.com> #4Feb 5, 2025 03:06PM

Also, I'm seeing this message in the Logcat:

"2022-06-12 18:47:15.156 1841-4562/? W/PackageManager: Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER"

pu...@gmail.com <pu...@gmail.com> #5Feb 5, 2025 03:07PM

Experiencing the same issues, please see my other report for any useful logs:

https://issuetracker.google.com/issues/235673375

vi...@google.com <vi...@google.com> #6Feb 7, 2025 02:02AM

+1, can confirm it doesn't work on Android 13:=

2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver }
2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Access blocked: ComponentInfo{xxx/xxx.WatchMessageReceiver}
2022-07-15 11:26:15.023   589-5347  ActivityManager         pid-589                              W  Unable to start service Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver } U=0: not found

pu...@gmail.com <pu...@gmail.com> #7Feb 10, 2025 03:33PM

Note that I've been able to make it work by:

Adding <action android:name="com.google.android.gms.wearable.BIND_LISTENER" /> in the intent filter
Removing <data android:scheme="wear" android:host="*" />

But I feel like this is not something we should do

pu...@gmail.com <pu...@gmail.com> #8Feb 11, 2025 10:32AM

I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨

vi...@google.com <vi...@google.com> #9Feb 13, 2025 04:47AM

If you're not targeting API 33 you're not affected by the bug. So it's a big bug, and yes we of course expected more from Google, but you can always target the api level later when it's fixed.

But I agree this is kind of desperating that more than 1.5 month after the first report nothing has changed.

ib...@google.com <ib...@google.com> #10Feb 14, 2025 05:28PM

As an interim update on this issue: we've been already working on the fix that should be available by Android 13 release. The fix requires thorough testing, I'll keep this bug updated as soon as we have more to share. Thanks!

pu...@gmail.com <pu...@gmail.com> #11Feb 14, 2025 05:55PM

@comment#9 The Play Store will eventually require targeting API 33, then 34, etc, so accepting this regression in a customer release would be a time ticking bomb for Wear OS apps.

Thank you for the update @comment#10

pu...@gmail.com <pu...@gmail.com> #12Mar 9, 2025 09:05AM

Hey @

comment#10

, do you have any news to share?

Android 13 is out today and we still have no patch unlike what you said a month ago