Flutter command for an Android release build and APK vs AAB difference.

WHAT THIS TESTS: This question probes two distinct but related release engineering basics: whether you know the exact Flutter CLI commands for Android release artifacts, and whether you understand the structural and delivery differences between a legacy APK and a modern Android App Bundle. At the senior level, interviewers care less about rote memorization and more about whether you can explain why Google Play prefers AAB and when an APK is still appropriate.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, name the two commands explicitly: flutter build apk produces a standalone APK, and flutter build appbundle produces an AAB. Second, describe the APK as a single monolithic archive that contains all resources and native libraries for every target ABI and screen density, which users or CI systems can install directly onto a device. Third, describe the AAB as an upload format that defers final APK assembly to Google Play; it contains compiled code and resources for all configurations, but Play uses Dynamic Delivery to generate, sign, and serve a smaller optimized APK tailored to the requesting device. Fourth, note the practical implication: AAB is the required or strongly recommended format for Google Play Store uploads because it reduces download size, while APK remains useful for internal testing, sideloading, or third-party distribution channels.

COMMON WRONG ANSWERS: Red flags include claiming that AAB is just a renamed or compressed APK, stating that flutter build is sufficient without specifying the target, saying that AAB files can be installed directly on a phone the same way as APKs, or asserting that APKs are deprecated and should never be used. Another warning sign is confusing debug and release flags, such as thinking --release is unnecessary because it is the default for those commands.

LIKELY FOLLOW-UPS: Interviewers often push deeper with questions about signing: where do you store the keystore, how do you configure key.properties, and what is the difference between upload and app signing keys. They may also ask about ABI filtering, asking why you might use --split-per-abi with APKs to mimic some AAB size benefits, or how to handle flavor-specific builds with --flavor. A senior candidate might also be asked about CI/CD automation and how to securely inject signing credentials during a GitHub Actions or Codemagic build.

ONE CONCRETE EXAMPLE: Imagine your team needs to distribute a test build to QA via Slack before the Play Store release. You would run flutter build apk --release to generate a single signed APK that QA can download and install directly on any Android device. For the production release, you would run flutter build appbundle --release, upload the resulting app-release.aab to the Google Play Console, and let Play handle dynamic delivery so that a Pixel user receives only the arm64-v8a libraries and xxhdpi assets, keeping their download roughly thirty percent smaller than the universal APK.