Reduce Flutter APK Size With ABI Splits and Verify the Right APK

One universal APK carries more native code

Flutter Android releases may include native libraries for multiple CPU architectures. A universal APK is convenient for testing, but it can be larger because it carries binaries a particular device will never load. For direct distribution, ABI splits can produce smaller artifacts for selected architectures:

flutter build apk --release --split-per-abi

The generated files are architecture-specific. Do not rename one generic app-release.apk in CI and assume every tester receives a compatible package.

Match the artifact to the device

Check a connected device's supported ABI with:

adb shell getprop ro.product.cpu.abilist

Then inspect each APK's native libraries and package metadata with Android build tools. Install the matching artifact on a clean device and exercise plugin paths that load native code. A successful build does not prove that the selected split contains every required library.

Keep artifact names that include the ABI, build variant, and version. In CI, publish all expected splits or use an app bundle distribution flow where the store selects device-specific resources. If using APK splits for sideloading, provide a clear selection mechanism and retain a universal fallback only when its size is acceptable.

Compare download size and installation behavior across representative devices. Some plugins ship architecture-specific binaries, and an omitted ABI can lead to a runtime load error even though the Dart layer starts. Validate the final artifact set after changing Flutter, Gradle, or plugin versions; native dependency contents can change independently of application code.