ExoPlayer: Crash in Assertions.checkArgument on Samsung Devices with Android 7.0
Issue description
Hi, since updating the ExoPlayer from 2.4.4 to 2.8.1, we noticed a significant amount of crashes on Samsung Devices with Android 7.0. Unfortunately, we haven’t been able to reproduce the crash ourselves - we are aware of the issue only due to Crashlytics reports. Therefore, this bug report certainly lacks some information, but maybe you might have an idea (or somebody might have encountered a similar problem) anyway. Even some explanation of possible reasons for this crash might help a lot.
Reproduction steps
From the logs, we know that the crash occurs after stopping a stream (using SimpleExoPlayer.stop()). The Player State becomes idle: onPlayerStateChanged, playWhenReady=true playbackState=1 and the DRM session is released. It seems to happen only for DRM protected streams and it does not happen every time a stream is stopped.
It might be worth noting that we are using a single ExoPlayer instance in several fragments within a ViewPager - users can switch streams by navigating within the ViewPager. However, the crash occurs not only when swiping left/right, but also when the user is stopping the stream in another way (e.g. by sending the app to the background).
Link to test content
I will email the link to dev.exoplayer@gmail.com using a subject in the format “Issue #1234”.
Version of ExoPlayer being used
2.8.1 - we will update to 2.8.2 soon, but from the release notes, I don’t think that this will fix our problem.
Device(s) and version(s) of Android being used
Android 7.0 only Samsung devices - most frequent devices:
- Galaxy Tab A 10.1 (42%)
- SM-J530F (7%)
- SM-J730F (6%)
- Galaxy J7 (2016) (4%)
A full bug report captured from the device
As mentioned above, I am unable to create a full bug report. This is the stack trace of the Crashlytics Crashes:
Fatal Exception: java.lang.IllegalArgumentException at com.google.android.exoplayer2.util.Assertions.checkArgument(SourceFile:39) at com.google.android.exoplayer2.upstream.DefaultAllocator.release(SourceFile:121) at com.google.android.exoplayer2.source.SampleQueue.clearAllocationNodes(SourceFile:609) at com.google.android.exoplayer2.source.SampleQueue.reset(SourceFile:111) at com.google.android.exoplayer2.source.SampleQueue.reset(SourceFile:98) at com.google.android.exoplayer2.source.chunk.ChunkSampleStream.onLoaderReleased(SourceFile:324) at com.google.android.exoplayer2.upstream.Loader$ReleaseTask.run(SourceFile:434) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607) at java.lang.Thread.run(Thread.java:762)
I’m sorry for the sparse information here - hopefully you can support me anyway.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 44 (19 by maintainers)
Commits related to this issue
- Add more information to unexpected assertion failure Issue: #4532 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=208968252 — committed to google/ExoPlayer by ojw28 6 years ago
- Add more information to unexpected assertion failure Issue: #4532 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=208968252 — committed to google/ExoPlayer by ojw28 6 years ago
- Remove assertion causing failure on some Samsung devices The assertion was so weak it probably wouldn't detect genuine misuse of the DefaultAllocator API, so it seems fine just to remove it. We don'... — committed to google/ExoPlayer by ojw28 6 years ago
- Remove assertion causing failure on some Samsung devices The assertion was so weak it probably wouldn't detect genuine misuse of the DefaultAllocator API, so it seems fine just to remove it. We don'... — committed to google/ExoPlayer by ojw28 6 years ago
Removal of the assertion will be in the next release.
Thanks. There’s a Galaxy Tab A 10.1 in the office, so I’ll try and get hold of it next week.
In the meantime, we’ve cherry-picked the more informative exception message into 2.8.4, which will be released soon. Once someone has captured a failure with this release, please share the message that you see! Note that the change will result in a slightly different stack trace (it’ll be the same down to
DefaultAllocator.release, but will no longer have theAssertions.checkArgumentline).Interesting, although intuitively I wouldn’t ever expect the design of the UI to result in a seemingly device specific assertion in this part of the player. As an initial step, what we’ll do is add more information to the exception that’s thrown (in the exception message). If this is a random VM/Proguard issue, then it’s possible that doing this might just make the issue go away. If it doesn’t go away, we’ll at least have a little bit more information about the failure.