AAB is short for Android App Bundle
An .aab is the publishing format Google Play requires for every new app (mandatory since August 2021). It contains all of your app's compiled code and resources, not one finished APK, but the pieces Google Play needs to build the right APK for each device.
That is the key difference: an AAB is not installable. You cannot send an .aab to someone and have them install it. Google Play takes your bundle, generates the optimized APKs for each screen size, language, and device architecture, signs them with your app signing key, and serves the right one to each user. A user on a small phone gets a smaller APK than a tablet user, and neither download contains code the other device cannot run.
Why Google made it mandatory
The old model was one APK for everyone, bloated with every language, density, and CPU architecture at once. The App Bundle lets Play split delivery by device, which typically shrinks download sizes by double-digit percentages and keeps app size limits manageable, including the 200 MB+ path for games via Play Feature Delivery.
For a developer it is mostly a workflow change: you build a bundle instead of an APK and upload that. The store handles the rest.
What this means when a tool gives you 'an aab'
If you used a builder and it handed you an .aab, that is the real, publishable artifact, the thing Google Play wants. It is not a placeholder. What it does not include is your Play Console listing, your screenshots, your privacy policy answers, or your review approval. Those still come from you.
Tapbound delivers the .aab as the Android artifact of every build. Your store submission build even keeps a stable package identifier, so re-submitting updates your existing listing instead of creating a second app.