Flutter command for an Android release build and APK vs AAB difference.
Flutter CLI release commands and Android distribution formats. Name flutter build apk and flutter build appbundle; note AAB lets Google Play generate optimized APKs per device while APK is a single direct-install file.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
When distributing a Flutter app, why does Google Play prefer an AAB over a universal APK?
- a.An AAB lets Google Play generate smaller optimized APKs tailored to each requesting deviceCorrect
- b.AAB files are smaller compressed APKs that users can sideload directly onto any device
- c.APKs are deprecated and cannot be uploaded to the Play Store anymore
- d.An APK uses Dynamic Delivery to serve only the resources a device needs after installation
Why? this is the answer
The card explains that an AAB is an upload format which lets Google Play assemble and serve smaller, device-specific APKs via Dynamic Delivery, whereas an APK is a single monolithic archive. Distractor A is a common misconception because AABs are not just compressed APKs and cannot be installed directly on a phone the way APKs can.
Just read this? Test yourself on what you have been reading.
Read the original → docs.flutter.dev
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on flutter — each one lists the topics its interview covers.
See open roles