Description
[REQUIRED] Issue description
I am experiencing thread deadlocks on the project I am working on. It uses the new media2 extension and the latest Exoplayer library artifact versions (2.12.0). The issue occurs when a non-default Executor is being set as a callback executor to a MediaLibraryService.MediaLibrarySession.Builder. The created MediaLibrarySession is connected to a SessionPlayerConnector.
[REQUIRED] Reproduction steps
I've attached thread dumps at the end of the report which display what's getting blocked and why.
The issue reproduction depends on changes of the buffering state being reported to SessionPlayerConnector.setBufferingState().
At some point MediaSessionImpl... is calling SessionPlayerConnector.getBufferingState() which internally posts a callback to the main thread's event loop, then blocks the thread
5F71
waiting for the callback to execute (SessionPlayerConnector.runPlayerCallableBlocking()). The problem is this is all happening while an internal lock is being held inside MediaSessionImplBase.createPlaybackStateCompat(), which will not be released until the main thread looper processes the posted callbacks. At the same on the main thread event queue there's a preceding callback which is trying to acquire the same lock, thus waiting forever.
To me it seems the preceding callback originates from a call to SessionPlayerConnector.notifySessionPlayerCallback() and has something to do with the following code and comments in SessionCallback's constructor:
// Register PlayerCallback and make it to be called before the ListenableFuture set the result. // It help the PlayerCallback to update allowed commands before pended Player APIs are executed. sessionPlayerConnector.registerPlayerCallback(Runnable::run, new PlayerCallback());
At the time of the deadlock there were 2 registered SessionPlayer.PlayerCallback/Executor pairs, the one from the comment above, and the second being a MediaSessionImplBase.SessionPlayerCallback tied to the media session's callback executor.
[REQUIRED] Link to test content
The issue isn't media content-specific, but related to state handling and a concurrency issue.
[REQUIRED] A full bug report captured from the device
bugreport-sdk_gphone_x86_64-RSR1.200819.001.A1-2020-09-29-12-01-30.zip
[REQUIRED] Version of ExoPlayer being used
2.12.0 (+ media2 extension)
[REQUIRED] Device(s) and version(s) of Android being used
This isn't device or API-specific, reproduced and reported with an Android 11 (API30) emulator, (Image rev. 8, emulator v30.0.26) on a Windows 10 machine