Media3's exoplayer crashes on initialization on some devices

[MRDHR]

Version

Media3 1.2.0

More version details

release

Devices that reproduce the issue

MBX/MagicBox_M13 MBX/MagicBox_T17 MBX/MagicBox_M17 MBX/MagicBox_M21A MBX/MagicBox_M18A ...

All the devices that crashed were Tmall's magic box and Tmall's magic screen. The crashed system included 6.1.0, 7.0.6 and 9.0.0.

Devices that do not reproduce the issue

Apart from Tmall's magic box and Tmall's magic screen, I have not seen any other crashes reported.

Reproducible in the demo app?

Yes

Reproduction steps

ExoPlayer.Builder(AppCore.getApplicationContext())
            .setMediaSourceFactory(
                DefaultMediaSourceFactory(
                    buildHttpDataSourceFactory()
                )
            )
            .setRenderersFactory(
                DefaultRenderersFactory(AppCore.getApplicationContext()).setEnableDecoderFallback(
                    true
                )
            )
            .build()

Expected result

App does not crash when exoplayer initializes

Actual result

App crashes when exoplayer initializes

The log of the crash is as follows:

androidx.media3.exoplayer.audio.AudioCapabilities.<clinit>(AudioCapabilities.java:79)
androidx.media3.exoplayer.audio.DefaultAudioSink$Builder.<init>(DefaultAudioSink.java:277)
androidx.media3.exoplayer.DefaultRenderersFactory.buildAudioSink(DefaultRenderersFactory.java:601)
androidx.media3.exoplayer.DefaultRenderersFactory.createRenderers(DefaultRenderersFactory.java:285)
androidx.media3.exoplayer.ExoPlayerImpl.<init>(ExoPlayerImpl.java:267)
androidx.media3.exoplayer.ExoPlayer$Builder.build(ExoPlayer.java:1201)
com.dhr.player.widget.ExoPlayerExt$player$2.invoke(ExoPlayerExt.kt:42)
com.dhr.player.widget.ExoPlayerExt$player$2.invoke(ExoPlayerExt.kt:30)
kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
com.dhr.player.widget.ExoPlayerExt.getPlayer(ExoPlayerExt.kt:30)
com.dhr.activity.PlayerActivity.initPlayer(PlayerActivity.kt:660)
com.dhr.activity.PlayerActivity.initView(PlayerActivity.kt:438)
com.dhr.common.activity.BaseActivity.onPostCreate(BaseActivity.kt:48)
android.app.Instrumentation.callActivityOnPostCreate(Instrumentation.java:1190)
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2389)
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2469)
android.app.ActivityThread.access$800(ActivityThread.java:151)
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1306)
android.os.Handler.dispatchMessage(Handler.java:102)
android.os.Looper.loop(Looper.java:135)
android.app.ActivityThread.main(ActivityThread.java:5374)
java.lang.reflect.Method.invoke(Native Method)
java.lang.reflect.Method.invoke(Method.java:372)
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:955)
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:750)

When I first tried to fix this crash, I found that no guava library was introduced into the project. After the introduction of guava31.1-android, test again. This error will still occur.

Media

any media

Bug Report

• [X] You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[MRDHR]

I also tried version 2.19.1 of exoplayer, and it crashed the same way.

[microkatz]

Hello @MRDHR,

Thank you for reporting your issue. Your clip of the stack trace seems to be missing the actual thrown error. Was it a thrown error of IllegalArgumentException for duplicate keys were added to an ImmutableMap?

If you could either attach or send the full bug report to android-media-github@google.com then that would be helpful for debugging.

[MRDHR]

Okay, as my existing device cannot reproduce it, I will compress the logs of each process and thread in the app and send them to email. Due to the time difference, I will need to send them to you tomorrow

[MRDHR]

Hello, I have sent the detailed log of the media3 issue #981 to the attachment. Please check

[MRDHR]

This is the log of anomalies that I can see so far. Because my own device can't be reproduced. It is impossible to provide a more detailed method of reproduction.

@microkatz

[microkatz]

@MRDHR

It appears that these issues are appearing due to mismatch of guava dependencies. Some other library you are depending on with your project is providing a differing version of the ImmutableMap class and is causing issues. I think you either need to resolve to a singular guava dependency version or try and upgrade that other library.

[MRDHR]

I had already checked before submitting the issue.

I don't think this problem is caused by the dependent version of guava. I checked that the dependent version of guava is 31.1-android. In addition, I also searched class ImmutableMap globally and found that there was a definition of the ImmutableMap class in XCldrStub and ImmutableMap.

[microkatz]

@MRDHR

In your issue post you said that this occurs with the demo application. Does this occur with the singular ExoPlayer demo application straight from the Github repo?

If there are not conflicting guava dependencies then maybe the file is being provided by other library. At least it was the case for this user who reported an error to the guava Github project, https://github.com/google/guava/issues/6002.

[icbaker]

Thanks for the additional logs. From the information provided it seems that this device is exposing a version of com.google.common.ImmutableMap on the application classpath (in the same way the normal Android SDK classes are exposed to the app), which is then being used in preference to the version of com.google.common.ImmutableMap bundled inside the APK. "Hidden API enforcement" in ART is then blocking the call to ImmutableMap.of, resulting in the crash. This call is blocked because com.google.common.ImmutableMap.of is not part of the public Android SDK. This explains why root cause is a NoSuchMethodError - because ART is making it look like the method doesn't exist

Caused by: java.lang.NoSuchMethodError: No static method of()Lcom/google/common/collect/ImmutableMap; in class Lcom/google/common/collect/ImmutableMap; or its super classes (declaration of 'com.google.common.collect.ImmutableMap' appears in /system/framework/libsetting.jar)

You can see the blocking being reported in the logs above the stack trace (log source):

Accessing hidden method Lcom/google/common/collect/ImmutableList;->of()Lcom/google/common/collect/ImmutableList; (blacklist, linking, denied)

Marking this as a device-specific issue because this device should not be exposing this class to apps since it's not part of the Android SDK. I suggest you report the issue to the device manufacturer. I'm afraid there's nothing we can do on the library side to avoid this issue (apart from remove all our usages of Guava, which we're not going to do).

[icbaker]

I'm going to close this. As described above, this device has misconfigured their Android OS build in a way that exposes Guava classes on the boot classpath but hasn't added them to the ART allowlist. This means any app using Guava on this device will be broken in this way. There's nothing we can do I'm afraid.

[MRDHR]

I have successfully solved the problem. My solution is. Fork guava, modify the package name of guava. Jar is packaged using mvn, and the java source code of failaccess.jar is referenced internally. Fork media3, modify all guava-related references to the modified package name.

At present, the test is successful in Tmall's magic box, and there is no crash.