[BUG] Playback fails in Release mode on Android (likely AGP 8.7 bug)

[DavoFranco]

Which API doesn't behave as documented, and how does it misbehave?
The audioPlayer.setAudioSource API fails to play plain HTTP streams when the application is built in release mode (flutter build apk). The player enters an error state. The exact same code and stream URL work perfectly when the app is run in debug mode (flutter run) on the same physical device.

Minimal reproduction project
We have not been able to isolate this into a minimal project due to the complexity of the build environment dependencies. The issue appears to be a direct result of the documented conflict between our Flutter version (which requires a modern AGP) and the just_audio/ExoPlayer bug on AGP 8.6/8.7. We believe any project using this toolchain combination and attempting to play a plain HTTP stream in release mode will encounter this issue.

To Reproduce (i.e. user steps, not code)
Steps to reproduce the behavior:

1. Create a Flutter project using a version compatible with AGP 8.7.0 (e.g., Flutter 3.22.2).
2. Add just_audio and just_audio_background dependencies.
3. Attempt to play a plain HTTP audio stream (e.g., http://190.128.136.2:8000/stream128).
4. Build a release APK with flutter build apk.
5. Install the generated app-release.apk on a physical Android device.
6. Attempt to play the stream. The player will fail.
7. Run the same project in debug mode on the same device. The stream plays correctly.

Error messages

There is no direct crash log from Flutter, as it's a native playback failure. The player state stream reports an error, and the UI shows a "Failed to load stream" message. This only happens in release builds.

Expected behavior
The stream should play correctly in release mode, just as it does in debug mode.

Smartphone (please complete the following information):

• Device: Google Pixel 8
• OS: Android 14+

Flutter SDK version

[√] Flutter (Channel stable, 3.32.2, on Microsoft Windows [Versi¢n 10.0.26100.4351], locale es-PY)
    • Flutter version 3.32.2 on channel stable at C:\FlutterSDK\flutter
    • Upstream repository [https://github.com/flutter/flutter.git](https://github.com/flutter/flutter.git)
    • Framework revision 8defaa71a7 (12 days ago), 2025-06-04 11:02:51 -0700
    • Engine revision 1091508939
    • Dart version 3.8.1
    • DevTools version 2.45.1
[√] Windows Version (11 Pro 64-bit, 24H2, 2009)
[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Platform android-35, build-tools 34.0.0
    • Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
    • Java version OpenJDK Runtime Environment (build 21.0.6+-13368085-b895.109)
    • All Android licenses accepted.
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.7.3)
[√] Android Studio (version 2024.3.2)
[√] VS Code (version 1.100.2)
[√] Connected device (4 available)
    • sdk gphone64 x86 64 (mobile) • emulator-5554 • android-x64    • Android 16 (API 36) (emulator)
    • Windows (desktop)           • windows       • windows-x64    • Microsoft Windows [Versi¢n 10.0.26100.4351]
    • Chrome (web)                • chrome        • web-javascript • Google Chrome 137.0.7151.104
    • Edge (web)                  • edge          • web-javascript • Microsoft Edge 137.0.3296.68
[√] Network resources
    • All expected network resources are available.
• No issues found!

Additional context
We have already tried all common solutions without success:

• Confirmed all necessary permissions (INTERNET, WAKE_LOCK, FOREGROUND_SERVICE, etc.) are in AndroidManifest.xml.
• Added comprehensive ProGuard/R8 rules (-keep and -dontwarn) for Flutter, ryanheise, and all Google/Firebase libraries.
• Added a network_security_config.xml to explicitly permit cleartext HTTP traffic.
• Programmatically set a standard browser User-Agent in the AudioSource headers.
  The issue seems to be a hard conflict between Flutter's requirement for a modern AGP and the documented bug in AGP 8.6/8.7 that affects ExoPlayer in release mode.

[ma-vai]

We are also experiencing the exact same issue. Starting with

just_audio: 0.10.0 
audio_session 0.2.0 

release mode builds do not play URL sourced audio, but it works fine in debug mode.
The latest versions of these two packages continue to have the issue.

Simple call in the code that remains unchanged:

await _musicPlayer.setUrl('$musicUrl');
_musicPlayer.play();

Throws a PlayerException of code 2 and message "Unexpected runtime error" in release mode.

From the package versions that introduced the issue, reverting back down one version each to

just_audio: 0.9.46
audio_session: 0.1.25

results in everything working normally again in both debug and release modes.

[nafiskabbo]

yes same issue facing with just_audio_background also

[hatemragab]

i have the same problem ! any fix ?

[alanstyong71]

For me, I've read the documentation in README and the AGP version conflicts with 8.6 and 8.7. I'm at version 8.10.1 so it's irrelevant. Then I looked at this to be added to app/build.gradle:

dependencies {
def exoplayer_version = "...specify-version-here...."
implementation "com.google.android.exoplayer:exoplayer-core:$exoplayer_version"
implementation "com.google.android.exoplayer:exoplayer-dash:$exoplayer_version"
implementation "com.google.android.exoplayer:exoplayer-hls:$exoplayer_version"
implementation "com.google.android.exoplayer:exoplayer-smoothstreaming:$exoplayer_version"
}

and started digging around Android documentation. The latest version of exoplayer is 1.7.1. But the issue is that if you use the above, it's gonna crash in build. So I used:

dependencies {
def exoplayer_version = "1.7.1"
implementation "androidx.media3:media3-exoplayer:$exoplayer_version"
implementation "androidx.media3:media3-exoplayer-dash:$exoplayer_version"
implementation "androidx.media3:media3-ui-compose:$exoplayer_version"
... (the rest of your dependencies)
}

Exoplayer has moved to a different library Media3.

Need to also add this in android/gradle.properties (if you haven't):

android.useAndroidX=true
android.enableJetifier=true

Not sure if you have other types of audioplayers, but I would remove them as they might mess things up.

And of course, the clean up:

flutter clean
flutter pub get
flutter build appbundle -v

This worked well for me. Just sharing and hope it helps.

[robertpaul75]

I can confirm that this issue occurs with just_audio version 0.10.4. When attempting to load an audio stream URL (which is in my case https), the following error is thrown:

06-18 14:31:59.457 1107 10920 V APM_AudioPolicyManager: getOffloadSupport: profile found
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: Playback error
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: c0.o: Unexpected runtime error
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: at c0.P.handleMessage(SourceFile:309)
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: at android.os.Handler.dispatchMessage(Handler.java:103)
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: at android.os.Looper.loopOnce(Looper.java:257)
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: at android.os.Looper.loop(Looper.java:342)
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: at android.os.HandlerThread.run(HandlerThread.java:85)
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: Caused by: java.lang.NullPointerException
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: at i3.b.getName(Unknown Source:1)
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: at c0.V.h(SourceFile:246)
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: at c0.P.l(SourceFile:34)
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: at c0.P.handleMessage(SourceFile:238)
06-18 14:31:59.458 25041 25447 E ExoPlayerImplInternal: ... 4 more
06-18 14:31:59.459 25041 25041 E AudioPlayer: TYPE_UNEXPECTED: null

To resolve this, I downgraded to just_audio version 0.9.46, which works without issues.

[ycv005]

Yes, I am facing same issue, and devoted 1 long day, but still figuring out what happen. Now, just check issue then I got to know. Thank for highlighting this.
[EDIT] - downgrading to just_audio version 0.9.46 works.

[ryanheise]

@DavoFranco , It will be helpful to know what is preventing you from switching to a supported AGP version?

[DavoFranco]

@DavoFranco , It will be helpful to know what is preventing you from switching to a supported AGP version?

Hi Ryan,

Thanks so much for getting back to us and for this great plugin. That's an excellent question, and it's at the core of the issue we're facing.

The reason we are unable to switch to a supported (older) AGP version is a dependency conflict with our Flutter SDK version.

Here's a detailed breakdown of the situation:

1. Flutter Version Constraint: Our project is built on Flutter 3.22.2. This modern version of Flutter requires a correspondingly modern version of the Android Gradle Plugin (AGP) and Gradle itself to build the project correctly.

2. Failed Downgrade Attempt: Following the advice in your documentation, our first instinct was to downgrade to a "safe" AGP version like 8.5.1 (which is not affected by the ExoPlayer bug). However, when we do this, the build fails with a clear error:

   Minimum supported Gradle version is 8.7. Current version is 8.4.
   This tells us that our Flutter project configuration is incompatible with the older toolchain. We are forced to use a newer version of Gradle, which in turn requires a newer AGP.

3. The "Catch-22" Situation: This leaves us trapped in a dependency conflict:

   • If we use a modern AGP (like 8.7.0), the project compiles successfully, but we hit the documented bug where ExoPlayer fails at runtime in release mode.
   • If we try to use an older, "safe" AGP (like 8.5.1) to avoid the bug, the project fails to compile due to incompatibility with our Flutter SDK's requirements.

We have tried multiple combinations and have also attempted to force a specific, newer version of androidx.media3:media3-exoplayer:1.3.1 in our build.gradle.kts, but the root AGP bug seems to override this fix in release mode.

We understand this is a complex toolchain issue, but any insight or potential workaround you might have would be greatly appreciated. We're happy to help test any potential solutions.

Thank you again for your time.

[ryanheise]

That answers why you didn't downgrade, but it doesn't answer why you didn't upgrade. You either need to use versions lower than 8.6/8.7, or versions "HIGHER" than 8.6/8.7. But I haven't heard from you why you can't try the latter either, and you are pinned to 8.7.

[DavoFranco]

That answers why you didn't downgrade, but it doesn't answer why you didn't upgrade. You either need to use versions lower than 8.6/8.7, or versions "HIGHER" than 8.6/8.7. But I haven't heard from you why you can't try the latter either, and you are pinned to 8.7.

Hi Ryan,

Thank you for the quick follow-up. That's an excellent question, and my apologies for not being clearer in the initial report.

You are correct, we did not explain why we couldn't upgrade. The simple answer is: we did try upgrading, but the issue persisted.

To be specific:

• Our Flutter version (3.22.2) forced us to use a newer Gradle version. We upgraded our project to use AGP 8.7.0 and Gradle 8.9.
• The project compiled successfully with this newer toolchain.
• However, when we built the release APK and tested it on the physical device, the exact same playback failure occurred. The stream would not play.

This result suggests that the bug might not be limited to just AGP 8.6/8.7, or that it might have another root cause in release builds.

After this failed, we then attempted to downgrade to a "safe zone" like AGP 8.5.1, which is when we ran into the build-time incompatibility with our Flutter version, trapping us in the "catch-22" I described.

I hope this clarifies the situation. It seems we are affected by the bug even on versions higher than 8.7. Thank you again for looking into this.

[ryanheise]

Thanks for the clarification. I did have someone report that it worked on 8.10 but since you've reported an issue with 8.9 which I was not aware of, I will investigate that. Note that in the pinned issue (from memory), someone also worked around this another way with Proguard rules, so that may be one other aspect to this that I can't see from your project since you didn't submit one in this bug report.

[DavoFranco]

Thanks for the clarification. I did have someone report that it worked on 8.10 but since you've reported an issue with 8.9 which I was not aware of, I will investigate that. Note that in the pinned issue (from memory), someone also worked around this another way with Proguard rules, so that may be one other aspect to this that I can't see from your project since you didn't submit one in this bug report.

Hi Ryan,

Thank you so much for the quick and insightful reply. You were right to ask why we didn't upgrade. Following your suggestion and feedback from the community, we've conducted more tests, and we have a critical new finding.

First, to clarify: We did try upgrading our toolchain to AGP 8.10.1 and Gradle 8.11.1. The project compiled successfully, but unfortunately, the original crash persisted on our test device (Google Pixel 8).

However, following the community's lead, we then focused on more specific ProGuard rules. After many attempts, our latest test yielded a partial, but very revealing, success:

New Finding:
With our current setup (AGP 8.7.0, Gradle 8.9), and after forcing androidx.media3 dependencies and adding specific -keep rules for androidx.media3.extractor.**, we are now seeing this behavior on a release build:

1. ABC Radio (HLS Stream): WORKS PERFECTLY. The stream at https://radiostreaming.abc.com.py/stream/playlist.m3u8 now plays without any issues. This confirms our general release setup (permissions, etc.) is correct.
2. Universo & Monumental (Progressive MP3/AAC Streams): STILL CRASH. The streams at http://190.128.136.2:8000/stream128 etc., now play for about half a second, and then the app crashes.

Conclusion:
This strongly suggests the bug is not with the HLS component of ExoPlayer/Media3, but is specifically related to the handling of progressive streams (like MP3/AAC) in release mode under this build configuration. The crash happens right after playback begins.

This seems to be the root cause. We wanted to provide you with this specific feedback, as it might help pinpoint the exact component that is being affected by the R8 optimization.

Thank you again for your time and for this amazing package. We will pause our debugging on this for now and explore other tasks, hoping that a future update might resolve this specific extractor issue.