Deadlock with android_content_provider
Documented behaviour
Loading artwork through an Android ContentProvider with the android_content_provider package.
Actual behaviour
Sometimes playing a new media item with an artUri using android_content_provider can freeze the app. It seems like a race condition causing a deadlock.
It hangs on this code: https://github.com/ryanheise/audio_service/blob/ed856d6a074ff6d4a9d9681b0a13993c1f51f4e8/audio_service/android/src/main/java/com/ryanheise/audioservice/AudioService.java#L639-L642
What I believe is happening:
- User plays item 1.
audio_servicecallssetMediaItemfor item 1.- This blocks the background thread and
AudioServiceclass in java because it's synchronized. - This completes normally.
- This blocks the background thread and
- User plays item 2.
audio_servicecallssetMediaItemfor item 2.- This again blocks the background thread and
AudioService.
- This again blocks the background thread and
- During this,
audio_servicereceives a callback from the OS for building the notification (buildNotification) for item 1.- This blocks the main thread for
audio_serviceas it has to wait for thesetMediaItemcall to complete.
- This blocks the main thread for
setMediaItemnever completes because theandroid_content_providerhangs while waiting for a response from our content provider.- I think that
audio_serviceis blocking the flutter thread while waiting for a response fromsetMediaItem, causing a deadlock whereandroid_content_providercan't send back a response to the java method.
- I think that
Here's an export of the threads in the hanged state: threads_report.txt
Removing synchronized from the code above fixes the issue, but I'm not sure of the consequences of doing this. Because of this, I think the issue lies within audio_service, but please let me know what you think so I can try and get this fixed!
Minimal reproduction project
https://github.com/puff/audio_service/tree/deadlock_content_provider
Reproduction steps
- Click play
- Spam next button - you may have to click fast to trigger the bug
Output of flutter doctor
[√] Flutter (Channel stable, 3.16.4, on Microsoft Windows [Version 10.0.19045.3803], locale en-US)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[!] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
X cmdline-tools component is missing
Run `path/to/sdkmanager --install "cmdline-tools;latest"`
See https://developer.android.com/studio/command-line for more details.
X Android license status unknown.
Run `flutter doctor --android-licenses` to accept the SDK licenses.
See https://flutter.dev/docs/get-started/install/windows#android-setup for more details.
[X] Chrome - develop for the web (Cannot find Chrome executable at .\Google\Chrome\Application\chrome.exe)
! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.8.3)
[!] Android Studio (not installed)
[√] IntelliJ IDEA Ultimate Edition (version 2023.3)
[√] Connected device (3 available)
[√] Network resources
! Doctor found issues in 3 categories.
Devices exhibiting the bug
Pixel 8 - Android 14
Hey @ryanheise, would you mind taking a look? If the solution really is as simple as removing the synchronized, that would allow us to finish up Android Auto support for the next release :)
I can also reproduce this bug (Zenfone 10, tested with Head Unit and actual car).
If you need any additional info, please let us know!
Hi, I just wanted to note that we were able to work around the issue by implementing our content provider in Kotlin/Java instead of Flutter. However, I want to leave this issue open because eventually it may become essential to access data from our Flutter app in our content provider, and this issue prevents that.
@puff Hi! I cannot reproduce this with latest version of android_content_provider (0.5.1). Can you confirm on your side or help me reproduce it, if it still persists?
(You might need to cherry-pick this commit in order to get it running + bump compileSdkVersion to 34)