Free HTML to You build your first Android app, click download, and suddenly there are two files: one ending in .apk and one ending in .aab. Which one do you send to your friend? Which one goes to Google Play? Can you just rename one into the other?
Short answer: the APK is for installing, the AAB is for publishing on Google Play. You almost always want both. Here is why, in plain language.
What an APK is
APK stands for Android Package. It is the file Android actually installs. Inside it is your app's code, its images and layouts, the manifest that describes the app (name, package name, permissions), and a digital signature that proves who built it.
An APK is complete on its own. You can copy it to a phone, tap it, and install it. You can attach it to an email, put it on your website, or hand it to a tester. Every app on every Android phone ends up as one or more APKs, even the ones that came from Google Play.
What an AAB is
AAB stands for Android App Bundle. Google describes it as a publishing format: it contains all of your app's compiled code and resources, but it leaves the final step, generating and signing the APKs, to Google Play.
That is the key difference. You cannot tap an AAB on a phone and install it. It is a package you give to the store, and the store turns it into installable APKs.
Why bother? Because phones are different. A budget phone with a small screen does not need the extra-large images made for a tablet, and a phone set to Spanish does not need your Japanese text. From one bundle, Google Play generates optimized APKs for each device configuration, so each phone downloads only the code and resources it needs. Users get smaller downloads, and you no longer have to build and manage a separate APK for every kind of device.
Why Google Play requires an AAB
Since August 2021, new apps on Google Play have had to be published as Android App Bundles. If you create a new app in Play Console today and try to upload an APK, it will not be accepted for that app. You upload the AAB, and Play takes it from there.
The bundle format also works with extra Play features such as Play Feature Delivery and Play Asset Delivery, which let large apps download parts of themselves later. For a typical small app built from a website or HTML files, you will not need those. The point is simply that the AAB is the ticket into the store.
Play App Signing and the upload key
Every Android app must be signed, and every update must be signed with the same key as the version already installed. Lose the key and you cannot ship updates to that app. That used to be a real risk for small developers, which is a big reason Google introduced Play App Signing.
With Play App Signing there are two keys:
- The app signing key. Google keeps this one on its own secure key infrastructure and uses it to sign the APKs that are delivered to users' phones.
- The upload key. You keep this one. You use it to sign your AAB before you upload it to Play Console, so Google knows the upload really came from you.
The nice part is what happens if something goes wrong. If you lose your upload key, or think someone else has it, you are not locked out of your app. You create a new upload key, export its certificate, and ask for a reset in Play Console. New apps are enrolled in Play App Signing automatically.
Even with that safety net, treat your key like the house keys of your app. Back it up somewhere safe, such as a cloud drive or a password manager, and use the same key file for every update.
Why you still want an APK
If Google Play only takes AABs, you might think the APK is obsolete. It is not. There are plenty of jobs only an APK can do:
- Testing on your own phone. Before you upload anything, you want to install the app and tap through every screen. An APK installs in seconds.
- Sharing with friends, clients or coworkers. Not every app belongs in a public store. An internal tool for a small team, a menu app for one restaurant, or a school project can simply be shared as an APK.
- Other stores and your own website. Some alternative app stores and many direct downloads still work with APK files.
- Quick checks before a release. If a tester reports a bug, you can send them a fixed APK in minutes instead of waiting for a store review.
One thing to know about sharing APKs: when Play App Signing is on, the copy users get from Google Play is signed with Google's app signing key, while the APK you build yourself is signed with your upload key. Android treats those as different signatures, so a phone that installed your own APK cannot simply update it from Google Play, and the other way around. For testers that is usually fine; just uninstall the test version before installing from the store. Also keep in mind that Google is rolling out developer verification for apps installed on certified Android devices, which affects APKs shared outside the store. We cover that in a separate article.
Quick comparison
- Install directly on a phone: APK yes, AAB no.
- Upload to Google Play as a new app: AAB yes, APK no.
- Who signs the final app users install: for an APK, you; for an AAB on Play with Play App Signing, Google, using the app signing key.
- Download size for users: an APK is the same file for everyone; from an AAB, Play generates smaller APKs per device.
How Free HTML to APK gives you both
When you build with Free HTML to APK, you do not have to pick one format and then figure out how to get the other. In the output step, choose APK + AAB and you get both from the same build:
- a signed APK to install on your own phone and share with testers, and
- an Android App Bundle, signed with your key, ready to upload to Play Console, where that key acts as your upload key for Play App Signing.
The website builder at freehtmltoapk.com works from a website URL, HTML files, a ZIP or a folder. It is free, needs no account and adds no watermark. You can let it create a signing key for you, or use the key file you already have (.jks, .keystore, .p12 or .pfx) when you are updating an existing app. If you prefer to work on the go, the Android app "HTML to APK: Website to App" builds the same way, right on your phone.
Whichever you use, the rule is the same: keep your key safe and build every update with it.
Which file do you need?
If you are testing or sharing directly, you need the APK. If you are publishing on Google Play, you need the AAB. If you are doing both, and most people are, build both and keep them together with your signing key.
Ready to make a bundle? See HTML to AAB for building one, and the Google Play publishing guide for every step from Play Console setup to your first release.