Crash on certain moto devices - MediaButtonReceiver has invalid component name

[ajaugust44]

Version

Media3 1.3.1

More version details

No response

Devices that reproduce the issue

Moto G Power 5G - 2024
Android 14

Devices that do not reproduce the issue

All other devices tested to this point. No other devices have had this issue according to crashlytics

Reproducible in the demo app?

Not tested

Reproduction steps

Users report that the app crashes immediately upon launch.
Steps:

• Using the specific device
• ??? (I have gotten this device and have been trying to reproduce with no success)
• Open the app

Expected result

The app should not crash

Actual result

The app crashes, with trace:

Fatal Exception: java.lang.RuntimeException: Unable to create service ***.service.AudioService: java.lang.IllegalArgumentException: Invalid component name: ComponentInfo{***/androidx.media3.session.MediaButtonReceiver}
       at android.app.ActivityThread.handleCreateService(ActivityThread.java:4808)
       at android.app.ActivityThread.-$$Nest$mhandleCreateService()
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2388)
       at android.os.Handler.dispatchMessage(Handler.java:111)
       at android.os.Looper.loopOnce(Looper.java:242)
       at android.os.Looper.loop(Looper.java:362)
       at android.app.ActivityThread.main(ActivityThread.java:8448)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:992)

Caused by java.lang.IllegalArgumentException: Invalid component name: ComponentInfo{***/androidx.media3.session.MediaButtonReceiver}
       at android.os.Parcel.createExceptionOrNull(Parcel.java:3061)
       at android.os.Parcel.createException(Parcel.java:3041)
       at android.os.Parcel.readException(Parcel.java:3024)
       at android.os.Parcel.readException(Parcel.java:2966)
       at android.media.session.ISession$Stub$Proxy.setMediaButtonBroadcastReceiver(ISession.java:478)
       at android.media.session.MediaSession.setMediaButtonBroadcastReceiver(MediaSession.java:321)
       at androidx.tracing.Trace$$ExternalSyntheticApiModelOutline0.m()
       at androidx.media3.session.MediaSessionLegacyStub$Api31.setMediaButtonBroadcastReceiver(MediaSessionLegacyStub.java:1443)
       at androidx.media3.session.MediaSessionLegacyStub.<init>(MediaSessionLegacyStub.java:210)
       at androidx.media3.session.MediaSessionImpl.<init>(MediaSessionImpl.java:220)
       at androidx.media3.session.MediaLibrarySessionImpl.<init>(MediaLibrarySessionImpl.java:81)
       at androidx.media3.session.MediaLibraryService$MediaLibrarySession.createImpl(MediaLibraryService.java:632)
       at androidx.media3.session.MediaLibraryService$MediaLibrarySession.createImpl(MediaLibraryService.java:120)
       at androidx.media3.session.MediaSession.<init>(MediaSession.java:657)
       at androidx.media3.session.MediaLibraryService$MediaLibrarySession.<init>(MediaLibraryService.java:605)
       at androidx.media3.session.MediaLibraryService$MediaLibrarySession$Builder.build(MediaLibraryService.java:587)
       at ***.service.AudioService.initializeSessionAndPlayer(AudioService.kt:247)
       at ***.service.AudioService.onCreate(AudioService.kt:180)
       at android.app.ActivityThread.handleCreateService(ActivityThread.java:4795)
       at android.app.ActivityThread.-$$Nest$mhandleCreateService()
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2388)
       at android.os.Handler.dispatchMessage(Handler.java:111)
       at android.os.Looper.loopOnce(Looper.java:242)
       at android.os.Looper.loop(Looper.java:362)
       at android.app.ActivityThread.main(ActivityThread.java:8448)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:992)

Media

This crash likely does not depend on the type of media. I will email a track of the media a user was trying to play.
The media is all DRM-free locally downloaded mp3 files.

Bug Report

• You will email the zip file produced by adb bugreport to [email protected] after filing this issue.

[ajaugust44]

I have seen another report of this issue in the Gramophone app repo: initial report and open issue.

[svenoaks]

I have this crash also, it only started after updating the app's targetSDK to 34. I'm using Media version 1.4.1 and it was also happening on Media version 1.2.0. Exactly like the OP's report, only happens on Motorola devices with Android 14, repetitively at app launch, making app unusable.

Have the receiver in the manifest, and playback resumption implemented

Here's additional devices I have logs on it happening on:

Moto G73 5G
Motorola Edge 40
Motorola Edge 50 Pro
Moto G84 5G
Moto G Power 5G - 2024
Moto G54 5G

I purchased one of these devices and could not reproduce it.

This is the largest user perceived crash I have atm, and starting to cause 1-star reviews. Cannot release updates with targetSDK 33 any longer, so would appreciate a workaround or bug fix

[marcbaechinger]

Thanks both for reporting.

Looks like these devices do not find the ComponentName for some reason and then throw here in MediaSessionRecord. The check that throws is new to Android 14 and is flagged.

I need to go educate myself internally regarding the flag that is involved. My guess is that switching your app to target SDK 34, enables that flag and then it throws.

If this is correct then you can verify this by finding a log line similar to the one below for the devices that do not repro, or then these devices do not have the root cause bug (which can be verified by testing BT playback resumption and seeing it working on such a device).

setMediaButtonBroadcastReceiver(): Ignoring invalid component name=

based on my understanding the above would be logged when the OS version is below 14 or the flag is disabled.

---

That doesn't tell the root cause why that component can't be found like on any other devices. At least playback resumption with BT works for me on Pixel with API 34 and tot, so going through that code path seems fine generally and according to not seeing this on other devices by telemetry

The ComponentName is read from the manifest by Media3 here. That component name is then used to register the receiver. The logs from the report above show the package name and the receiver classname which is what makes a ComponentName. The system then does the same query here. Given Media3 doesn't invent a component name but gets it from the manifest from which the system is reading it on most devices as well, I can't give you a useful answer right now.

I need to raise this internally so we can probably hear what the oem thinks about it.

[marcbaechinger]

If some of you can provide us with some stats around how many of these devices fail in proportion of not failing, that would be helpful. Is it only a small fraction of users with a given model?

I wonder why you can't repro and that would be helpful to know. If it's just a few, it could be that the have some settings different to common users. Like disabled playback resumption in the settings or something.

[svenoaks]

Hard to get precise stats and it is small rollout, but checked crashlytics vs analytics numbers and have 48 /108 users with Android 14 with those devices have the crash. Not sure how accurate that is, but it seems probable based on other data in crashlytics

Not all Android 14 Moto devices have the crash, the others don’t have it at all.

Not sure that option to disable playback resumption is still there, I don’t see it on the Moto or a Pixel with Android 14. Is it “Pin media player”?

I’m guessing there’s either some variants of the devices that it only happens on, or some common user behavior that triggers it, will try to repro a bit more

[ajaugust44]

Ditto to the difficulty of getting accurate stats. I'm sticking with crashlytics, as the play console is giving me very weird numbers. I'm including our install count for the devices on the list svenoaks provided as well

In the last 30 days:

Device	Crash count	Active users
Moto G power 5g 2024	9	21
Moto G73 5G	1	1
Motorola Edge 40	0	2
Motorola Edge 50 Pro	0	2
Moto G84 5G	0	11

Hope this helps! I can reach out to the users who have reported the issue to see whether they have changed their playback resumption settings.

[ajaugust44]

One user with this issue has responded to report that they have playback resumption (pin media player setting) enabled.

[ajaugust44]

Excited to see the exception catch in that commit- may I ask when the change might be released? We are considering whether to mitigate the issue for these users on our end, but only if this fix won't be released soon.

[marcbaechinger]

This is part of the 1.5 release which isn't coming super soon I'm afraid. We are in alpha now and expected stable release is begin of December.

[svenoaks]

Excited to see the exception catch in that commit- may I ask when the change might be released? We are considering whether to mitigate the issue for these users on our end, but only if this fix won't be released soon.

Just wondering if you had a way to mitigate this issue on those devices on the app side? Or build media3 locally with the workaroud and add that fix?

[tonihei]

Or build media3 locally with the workaroud and add that fix?

That may work, we'll also publish the next pre-releases like 1.5.0-beta01 end of this month or so. This may be the easiest way to get the fix if you can wait that long, otherwise locally applying this fix sounds like the only option given where the fix has to go... (unless @marcbaechinger sees another workaround that can be done in app code?)

[ajaugust44]

build media3 locally with the workaroud and add that fix?

We were thinking of creating a separate build without the MBR in the manifest, and putting it in a closed release channel for users who reach out with the issue. Nothing clever.