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.

[marcbaechinger]

I got some feedback from Motorola as in 'can not reproduce'. I sent an APK for reproduction but I couldn't really create enthusiasm in trying to repo the behaviour. I didn't get more than installing the APK and saying: "no repro". It was a little bit like feeling that I'm needlessly stealing time from Mototora engineers that actually have more important things to do. I apologize to the vendor if that wasn't the case, I was acting in the name of our users. :)

I eventually got a note:

Settings path: Settings - Battery - Manage background apps.

If the app is set to Don't allow, app will not be allowed to run 
in the background and its auto-start will be blocked 
(Component won't be found, including Broadcast Receiver).

I think this exactly matches to what we see here. If some of you have such a device, can you try to repro this way? Like use that setting to disallow background playback and then try again.

If this repros, we have the root cause for these stack traces. I asked whether there is an API for apps or libraries to know that the user has selected this option, and the answer is no, the is not such API.

Well then, it looks like the fix we have for this from above is going to stay, unless Motorola finds a way to change the system in a way that would allow apps to react appropriately to such differences.

[svenoaks]

It did in fact repro on Moto G73 5G by setting the app to "Don't allow" under "Background app use". After allowing the service to die naturally in the background, I tried resuming playback with a bluetooth play button. This didn't work and did not throw the exception. But going back into the app from the launcher (putting the app in foreground!) caused it to throw immediately and repeatedly.

Close to positive this will happen with the default "Smart use" setting eventually, as users with these devices report having to uninstall and reinstall the app to get it to stop crashing after it starts crashing after some time.

Is b884d7e in 1.5.0-alpha01 ? I tried it and it crashes the same, not sure if it work even if it caught it though, service might just not start?

Seems like Motorola needs to fix this, it's a vendor battery optimization that is breaking Android, and I'd guess it affects other apps, not just those that use Media3.

[svenoaks]

As a temporary workaround, users of these devices could be told to set "Background app use" to "Always allow", seems to prevent it. I tried it switching it back and forth a few times, one time it required me to clear the storage of the app before it stopped crashing.

Note: this a second app level battery optimization, it's under Settings...Battery...Background app use. It's not the "App battery use" under "App info" for the app with the settings Unrestricted, Optimized, Restricted.

[ajaugust44]

While using a Moto G Power 5G - 2024 as my main test device I have not been able to reproduce this crash.

Today I'm testing with restricted battery usage, with both the system battery restriction that the Moto engs and svenoaks describe and the app settings battery restriction, and I still have not reproduced the issue- I feel the moto folks' pain, even if I don't appreciate their unwillingness to dig deeper.

I'll send these steps to the users who have reached out with the issue to see whether setting the battery restriction to "Always allow" fixes the issue.

[marcbaechinger]

Thanks both for checking. I was wondering whether the fix in place is sufficient in case a user that sets that option doesn't expect playback resumption over BT to work because that would require background playback. If a user is aware of this, then they do not consider this a bug. The fix in place then catches the exception so it doesn't hurt apps that see a stack trace.

Bad ratings from users reported above tell my assumption of that awareness doesn't really apply I'm afraid.

I think this is how far we can get it for now from the library side. I'm glad the vendor was able to tell us what is the cause of the behavior.