Fixing a Flutter Release APK Build That Failed on Windows

Ikegbo Ogochukwu — Thu, 16 Apr 2026 13:27:12 +0000

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:

verify whether the first error is actually environmental
retry once the environment is healthy
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"
}

The Flutter Release Gauntlet: How to Build Your First Android APK Without the Headache

Ikegbo Ogochukwu — Thu, 16 Apr 2026 13:03:10 +0000

You’ve spent weeks perfecting your Flutter app. The widgets are beautiful, the state management is solid, and it runs perfectly on your emulator. But now comes the real challenge: getting it onto a real device.
In this guide, we’ll skip the fluff and look at exactly how to build and share your first Android APK.

1. The Quick & Dirty: Generating Your First APK

If you just want to send a file to your friend or client right now, the standard command is your best friend:

flutter build apk --release

What’s happening here?
Flutter is "tree-shaking" your code—removing unused resources—and compiling your Dart code into a high-performance release binary. Once finished, you’ll find your prize at:
build/app/outputs/flutter-apk/app-release.apk.

2. The "Fat APK" Problem (and the Solution)

The standard build command creates a "Fat APK," which contains code for all device architectures (arm64, armeabi, x86_64). While convenient, it makes your file size unnecessarily large.
To create smaller, optimized files for specific devices, use:

flutter build apk --split-per-abi

This gives you three separate APKs. Most modern phones will use the app-arm64-v8a-release.apk version.

3. Signing Your App (Don't Skip This!)

Android won’t let you install a "blank" app for long. To make your app official, you need a digital signature called a Keystore.

Generate the key: Use the keytool command in your terminal to create a .jks file.
Reference it: Create a key.properties file in your android/ folder to store your passwords.
Update Gradle: Configure your android/app/build.gradle to use these credentials during the build process.

Pro Tip: Never, ever upload your key.properties or .jks file to GitHub. Add them to your .gitignore immediately.

4. APK vs. App Bundle (AAB): Which one do you need?

Use APK for direct sharing (WhatsApp, Google Drive, or Slack).
Use AAB (flutter build appbundle) for the Google Play Store. Google now requires AABs because they allow the store to generate the smallest possible APK for every specific user.

5. Final Checklist Before You Share

Change the App Name: Update the android:label in your AndroidManifest.xml so it doesn't just say "Flutter App" on the home screen.
Update the Package Name: Change com.example.yourapp to something unique like com.yourname.appname.
Add an Icon: Use the flutter_launcher_icons package to replace the default Flutter logo with your own branding.

Summary Table: Your Build Toolkit

Goal	Command	Output
Quick Test	flutter build apk	Fat APK
Small File	flutter build apk --split-per-abi	Multiple ABI-specific APKs
Play Store	flutter build appbundle	.aab file
Clean Start	flutter clean	Clears old build files

DEV Community: Ikegbo Ogochukwu