Choose Flutter APK or App Bundle for the Right Release Check

Do not compare the outputs as interchangeable files

flutter build apk --release creates an installable APK artifact. flutter build appbundle --release creates an Android App Bundle intended for distribution through a store or compatible delivery pipeline. An AAB is not installed directly with adb install like a universal APK.

Use the artifact that matches the question. For a quick local smoke test, build an APK for the target architecture and install it. For store delivery, build the AAB and validate the generated splits with bundletool or the distribution test track.

Verify signing and configuration

Before shipping, confirm the release signing configuration is selected and that the application ID and version code match the intended track. A debug-signed APK can prove the code launches but cannot prove the store upload path is configured. Never commit a keystore password or private signing key into the repository.

Inspect the output directory and keep artifact naming explicit in CI so a file copied from a prior build cannot be mistaken for the current release. Test the AAB-derived device configuration on a clean emulator or internal track, including a device with a different ABI if that matters to your audience.

If an APK works but the store-delivered app fails, compare split resources, manifest values, signing identity, and dynamic feature delivery. The artifact format changes the delivery path, so a successful local APK is necessary evidence for app behavior but not a complete validation of the store release.

Match the artifact to its distribution path

An APK is a directly installable package, useful for local testing, managed deployments, and services that accept APK uploads. An Android App Bundle is a publishing format from which a distribution service can generate device-specific APKs. The bundle is not itself installed with adb install in the same way as a universal APK. Choose the format based on the receiving channel rather than assuming one is universally better.

For a bundle release, test through the distribution service's internal testing path or the appropriate bundle-to-APK tooling. A locally generated universal APK can help debug, but it may not reproduce the split APK selection that a store delivers to a device. For an APK release, confirm ABI and density coverage and whether the artifact is universal or split. State the artifact type and intended audience in release notes so testers do not try to install a publishing bundle directly.

Validate identity, signing, and upgrade behavior

Before publishing, inspect the application ID, version code, version name, signing identity, and minimum supported Android version. For split outputs, ensure the set of APKs corresponds to the target device configuration. Test installation on a clean device and update installation over the previous supported version. A clean install catches missing runtime assets; an update catches signature and migration issues that do not appear on a blank emulator.

Keep debug and release signing separated. A debug APK can prove the code launches but cannot prove the store upload path is configured. A bundle signed with an unexpected key may be impossible to publish as an update. Protect signing material and verify the fingerprint through the release process. Do not put private signing credentials in the repository or public build logs.

For CI, archive the exact output file and record a checksum, build number, flavor, and toolchain. Run a smoke test using the same delivery route intended for testers. If installation fails, capture the install source, device API level, artifact type, and package-manager message. Build success proves compilation, not delivery or upgrade compatibility.

Retain artifacts long enough to reproduce a tester report, but restrict access to internal or signed builds according to company policy. Attach the checksum and build metadata to the release record rather than relying on a filename. When a test fails, compare the downloaded artifact with CI's archived artifact before rebuilding; otherwise the investigation may unknowingly test a different binary.

Run an upgrade test from the previous supported release as well as a clean install. Version code ordering, signing identity, and migration code are not exercised by a blank emulator. If a bundle produces split APKs, test at least one device configuration with the architecture and density the release claims to support. Keep the artifact type explicit in the test report so a successful APK smoke test is not mistaken for proof that store delivery works.