java.lang.IllegalArgumentException: session is already released

[PaulWoitaschek]

Media3 Version

Media3 1.0.1

Devices that reproduce the issue

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Not tested

Reproduction steps

1. Rollout Voice 7.0.12:
   https://github.com/PaulWoitaschek/Voice/blob/7.0.12/playback/src/main/kotlin/voice/playback/session/PlaybackService.kt
2. See crashes in Crashlytics

Expected result

It doesn't crash

Actual result

I'm seeing multilpe permutations of this crash.

The biggest one is this, which is strange because that version of Voice does not declare any MEDIA_BUTTON receiver.

Fatal Exception: java.lang.RuntimeException: Unable to start service voice.playback.session.PlaybackService@60513f1 with Intent { act=android.intent.action.MEDIA_BUTTON dat=androidx.media3.session.MediaSessionImpl:/2360112758 flg=0x10000000 cmp=de.ph1b.audiobook/voice.playback.session.PlaybackService (has extras) }: java.lang.IllegalArgumentException: session is already released
       at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:4808)
       at android.app.ActivityThread.access$2100(ActivityThread.java:271)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2163)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loopOnce(Looper.java:210)
       at android.os.Looper.loop(Looper.java:299)
       at android.app.ActivityThread.main(ActivityThread.java:8250)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:556)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1045)

Caused by java.lang.IllegalArgumentException: session is already released
       at androidx.media3.common.util.Assertions.checkArgument(Assertions.java:1)
       at androidx.media3.session.MediaSessionService.addSession(MediaSessionService.java:10)
       at androidx.media3.session.MediaSessionService.onStartCommand(MediaSessionService.java:120)
       at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:4790)
       at android.app.ActivityThread.access$2100(ActivityThread.java:271)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2163)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loopOnce(Looper.java:210)
       at android.os.Looper.loop(Looper.java:299)
       at android.app.ActivityThread.main(ActivityThread.java:8250)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:556)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1045)

Media

not media related

Bug Report

• You will email the zip file produced by adb bugreport to dev.exoplayer@gmail.com after filing this issue.

[marcbaechinger]

Thanks for your report!
This is puzzling indeed.

that version of Voice does not declare any MEDIA_BUTTON receiver.

All these crashes are on devices with Android 12 and below (at least if sonstige (1) isn't Android 13). It looks to me as this is a PendingIntent sent from a notification that arrives in onStartCommand. I think this part is working as intended.

The exception is thrown because the session is already released. Which is a bit strange when looking at your service implementation (which, as an aside, looks quite slick with the injection approach :). It doesn't seem that you ever call session.release() except onTaskRemoved and onDestroy() is called. Which should terminate the service immediately and together with releasing the session the notification is removed.

It's quite odd, that the session that is returned here is then, two lines below when passed to addSession(session) already released.

From your code (that looks correct to me), an explanation would be that there is a race between onTaskRemoved() and receiving the onStartCommand call with the media button. However, this is a long shot and I don't know how this manually should be performed by a user.

It may be cause by a memory leak of the service, that is fixed since 1.0.2 (see #346).

So what I would try:

(1) You can check with canary leak whether your current app exhibits the memory leak problem. This still wouldn't explain why there is still a notification when the session is released, but this would be interesting to now. If that's the case upgrading to 1.0.2 is an option.

(2) If my above guessing is true, you could try to change onGetSession in your service to return null when session.isReleased() returns true.

I think that this could be a workaround. We could even do this check ourselves in MediaSessionService. Although without better understanding why this happens, this is a bit of a guess work.

Can you give me an idea on how many users are affected (proportionally to all users)?

Sorry for not being able to get a better answer for now,

[PaulWoitaschek]

Thanks for your help!

(1) You can check with canary leak whether your current app exhibits the memory leak problem. This still wouldn't explain why there is still a notification when the session is released, but this would be interesting to now. If that's the case upgrading to 1.0.2 is an option.

I added leakcanary but it did not detect any leaks so far.

(2) If my above guessing is true, you could try to change onGetSession in your service to return null when session.isReleased() returns true.

I can't do that as it's package private.

Can you give me an idea on how many users are affected (proportionally to all users)?

Voice 7.0.12 (the one where this was originally reported)

• I can see 13772 users
• this crash affected 118 users
• It's 99% in the background

Voice 7.0.14

• Uses Media 1.0.2
• 9382 users
• 51 users affected
• 93% in background

[PaulWoitaschek]

Okay, entering the badlands now: PaulWoitaschek/Voice@773a406

[PaulWoitaschek]

@marcbaechinger
This actually solved the crash!

[mhelder]

Just dropping a comment here to maybe add some additional information.

We're seeing the same crash logged in Crashlytics using media3-1.2.0. Exact same stack trace as posted up top, albeit some different line numbers in various places. Some stats:

• ~5000 app users (we have 20k+ in total, but are currently doing a staged rollout for the migration to media3)
• 38 users affected
• 63 crash events
• 100% in background
• 100% on Samsung devices
• 100% on Android 14

Please note that the Samsung + Android 14 stats may be a coincidence/market reflection of our user base and their locality.

Crashlytics also labels this as "early crash", saying: 92% of crash events for this issue happened in the first 5 seconds of a user's session.

We're still investigating repro steps. In the meantime, I was wondering if there were any new insights in what could be causing this issue? I could blindly apply the suggested workaround to see if the issue goes away of course, but I as @marcbaechinger suggested: it'd be good to have a better understanding why this happens. Given that the aforementioned workaround requires reflection, I can't help but wonder if this should maybe be patched in the media framework instead?