How does App Bundle handle ABI splits versus multi-APK?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.

Source: developer.android.com