How does App Bundle handle ABI splits versus multi-APK?
Tests dynamic delivery of native libs: AAB auto-generates per-ABI config splits, but multi-APK requires manual APK builds per ABI. Misconfiguration ships unused .so bloat or crashes on unsupported devices. Red flag: calling AAB a simple multi-APK zip.
What's really being asked
This question probes whether you understand the difference between build-time artifact management and install-time dynamic delivery, specifically for native libraries. A senior candidate should know that the App Bundle shifts responsibility for ABI filtering from the developer to Google Play, and should be able to articulate the mechanical differences between split config APKs and manually published multi-APKs.
The full answer
Four things in order. First, explain that an Android App Bundle contains all ABIs in the uploaded artifact, but Play generates a base APK plus a set of config splits, including one per ABI. At install time, the device receives only the base APK and the single config APK matching its ABI, so it downloads only the .so files it needs. Second, contrast this with the legacy multi-APK approach, where the developer must manually build multiple APKs, each stripped to a single ABI, sign them all, assign version codes carefully, and upload them together; Play then chooses the best matching APK at install time. Third, describe the failure mode of misconfiguration: if you disable ABI splits in the bundle configuration or accidentally bundle all native libraries into the base module, Play cannot split them, and every device downloads a universal APK containing all ABIs, inflating download size by several megabytes per ABI. Fourth, mention that in multi-APK, misconfiguration usually means missing an ABI variant, which causes the app to be unavailable for that architecture, or using overlapping version codes that confuse Play's serving logic.
The mistakes people make
Saying that the App Bundle is just a zip of multiple full APKs, one per ABI. Claiming that Play strips out .so files on the device at runtime rather than serving split APKs at install time. Asserting that multi-APK and AAB produce the same end-user result with no operational difference for developers. Saying that failing to configure ABI splits causes runtime crashes rather than install bloat.
What usually comes next
How would you handle a device that sideloads the base APK without the config split? How do version codes work when Play combines a base APK and a config APK? What happens if you need to support a custom native library for only one ABI? How does Play Asset Delivery differ from ABI splits for large native assets?
A concrete example
Suppose your app ships armeabi-v7a, arm64-v8a, x86, and x86_64 libraries totaling 12 MB per ABI. With a correctly configured App Bundle, an arm64-v8a user downloads roughly the base module plus 12 MB of native code. If you mistakenly disable ABI splits in the bundle configuration or put the .so files in the base module assets instead of the jniLibs directory, that user receives all 48 MB of native libraries, wasting 36 MB per install across millions of users. In the old multi-APK model, you would have built four APKs and assigned rising version codes; forgetting the x86 variant would simply block x86 devices from installing the app entirely rather than bloating them.
Interview question
How does dynamic delivery of native libraries differ between a correctly configured App Bundle and the legacy multi-APK approach?
- a.The App Bundle is simply a compressed archive containing multiple full APKs stripped per ABI, and Play selects the correct one at install time.
- b.The App Bundle requires developers to manually build and sign one APK per ABI, while multi-APK automatically generates config splits at install time.
- c.Both approaches produce identical install-time behavior, but the App Bundle reduces build time by zipping the APKs together before upload.
- d.The App Bundle uploads all ABIs in one artifact and Play serves a base APK plus a single ABI config split, whereas multi-APK requires the developer to build, sign, and version separate APKs per ABI.Correct
Why? this is the answer
A correctly configured App Bundle lets Play generate a base APK and a per-ABI config split at install time, while multi-APK forces developers to manually build and version separate APKs. Option A is wrong because an App Bundle is not a simple zip of full APKs; it is a publishing format that Play uses to generate optimized config splits dynamically.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #app-bundle
- #native-libraries
- #abi
- #google-play
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
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 android — each one lists the topics its interview covers.
See open roles