Fixing a Flutter Release APK Build That Failed on Windows

How I diagnosed a misleading Gradle failure, separated a temporary Maven network issue from the real Android packaging problem, and fixed the release APK build with a small Gradle change

Introduction

I was building a Flutter release APK on Windows for tester distribution and ran into a confusing sequence of build failures.

The first error looked like a dependency-resolution problem:

Could not GET 'https://repo.maven.apache.org/...'
No such host is known (repo.maven.apache.org)

That made it look like the project or Firebase setup was broken.

After retrying once the network recovered, the real build blocker appeared:

Execution failed for task ':app:extractReleaseNativeSymbolTables'.
Failed to create MD5 hash for file ... libflutter.so.sym.temp-stream ...

This is the kind of issue that wastes time because the first failure distracts you from the second one. The Maven error was temporary. The actual release-build problem was native symbol extraction during Android packaging on Windows.

This post explains how I diagnosed it and the small fix that got the APK building successfully.

The goal

The goal was simple:

• produce a signed release APK
• share it directly with testers
• avoid changing unrelated parts of the Android build

The project already had release signing configured, so this was not a keystore or package-name problem.

Step 1: Separate the temporary network error from the real build issue

The first failure was:

Could not resolve all files for configuration ':firebase_core:releaseRuntimeClasspath'
Could not download error_prone_annotations-2.26.0.jar
No such host is known (repo.maven.apache.org)

That is not a Flutter code issue.

It means Gradle could not reach Maven Central at that moment. Before changing any project files, I verified whether the host was reachable from the machine.

Useful checks on Windows:

nslookup repo.maven.apache.org
Test-NetConnection repo.maven.apache.org -Port 443

Once Maven Central was reachable again, the dependency download issue disappeared.

That was important, because fixing the wrong problem would have been wasted effort.

Step 2: Retry the build and read the next failure carefully

After the network issue cleared, the build failed again, but with a different error:

Execution failed for task ':app:extractReleaseNativeSymbolTables'.
Cannot access output property 'outputDir' of task ':app:extractReleaseNativeSymbolTables'.
Failed to create MD5 hash for file ... libflutter.so.sym.temp-stream ... as it does not exist.

This pointed to Android native symbol extraction, not Firebase, not signing, and not dependency resolution.

That distinction matters.

By this point, the release APK build was already far enough along to show that:

• Flutter dependencies were resolving
• Firebase packages were not the main blocker
• the Android project structure was basically valid

The failure was happening in the release packaging phase.

Step 3: Identify what was actually safe to disable

For a tester APK, I did not need packaged native debug symbols.

That made the fix straightforward: disable native debug symbol packaging for the release build.

In android/app/build.gradle.kts, I updated the release build type to set:

ndk {
    debugSymbolLevel = "none"
}

The relevant release block became:

buildTypes {
    release {
        isMinifyEnabled = true
        isShrinkResources = true
        ndk {
            debugSymbolLevel = "none"
        }
        if (hasKeystoreConfig) {
            signingConfig = signingConfigs.getByName("release")
        } else {
            signingConfig = signingConfigs.getByName("debug")
        }
    }
}

This was a targeted fix. It did not relax signing. It did not remove shrinking. It only stopped the build from trying to package native debug symbols that were triggering the failure.

Step 4: Rebuild the APK

From the Flutter project root, I reran:

flutter pub get
flutter build apk --release

After the debugSymbolLevel = "none" change, the build completed successfully and produced:

build\app\outputs\flutter-apk\app-release.apk

In my case, the resulting APK was about 64.5 MB, which was fine for direct tester distribution.

Warnings that looked scary but were not the blocker

During the build, there were also warnings like these:

source value 8 is obsolete
target value 8 is obsolete

and:

Font asset "MaterialIcons-Regular.otf" was tree-shaken

Those warnings were not what caused the release build to fail.

It is worth calling that out because large build logs often mix harmless warnings with the real failure, and it is easy to chase the wrong thing.

Why this fix made sense

This was a pragmatic release-build decision.

For a tester APK, the priority was:

• get a stable release artifact
• keep minification and shrinking enabled
• avoid unnecessary Gradle/NDK packaging work that was failing on this environment

If I were setting up a more advanced crash-symbol workflow later, I could revisit symbol generation in a more controlled release pipeline. But for immediate tester distribution, disabling native debug symbol packaging was the right tradeoff.

Final takeaway

The key lesson was not just the Gradle fix. It was the debugging sequence:

1. verify whether the first error is actually environmental
2. retry once the environment is healthy
3. fix the first reproducible project-level failure, not the first scary message in the log

In this case:

• the Maven Central error was temporary network/DNS trouble
• the actual reproducible blocker was extractReleaseNativeSymbolTables
• the successful fix was setting debugSymbolLevel = "none" in the release build

If your Flutter release APK build fails on Windows during native symbol extraction, and you do not need packaged native symbols for that build, this is a clean fix worth trying.

Build command recap

flutter pub get
flutter build apk --release

Gradle fix recap

ndk {
    debugSymbolLevel = "none"
}