Quick answer: to put a ZIP-built app on Google Play you need (1) a Pro build that outputs an AAB signed with your own keystore; (2) a Google Play developer account ($25 once); (3) a store listing with a 512 px icon, a 1024 × 500 feature graphic, at least two screenshots and a description; (4) a public privacy policy URL; (5) the content rating, data safety and target audience forms; and (6) for new personal accounts, a closed test with 12 testers for 14 days before production. Then upload, submit, and wait one to three days for review.
Why an AAB and not the APK
Since 2021 Google Play requires new apps to be uploaded as an Android App Bundle (.aab). A bundle is not installable itself; Play uses it to generate optimised APKs per device. For a WebView app the difference is invisible to users, but the rule is absolute. The free tier builds APKs for direct install; Pro builds the AAB from the same ZIP, signed with a keystore you provide or generate. The signing guide explains why the key must be yours.
Step 1 — The developer account
Register at play.google.com/console. One-time $25 fee, identity verification (a government ID for personal accounts; a D-U-N-S number for organisations), and a developer name that appears on every listing. Personal accounts created since late 2023 must run a closed test with at least 12 testers opted in for 14 continuous days before they can publish to production — plan for that in the timeline.
Step 2 — Build the AAB
In the builder, with Pro: choose AAB as the output, upload your keystore (or generate one and download it — keep it forever), fill in the package name and version, and build. Note the package name cannot change after the first Play upload, and every later upload needs a higher versionCode — the version planner keeps that straight.
Step 3 — Create the app and the listing
Play Console → Create app: name, default language, app or game, free or paid (free cannot later become paid). Then the Main store listing:
| Field | Requirement |
|---|---|
| App name | Up to 30 characters |
| Short description | Up to 80 characters; shown in search results |
| Full description | Up to 4000 characters; no keyword stuffing, no comparisons to other apps |
| App icon | 512 × 512 PNG, opaque — the icon maker exports it |
| Feature graphic | 1024 × 500 — the feature graphic maker |
| Phone screenshots | 2 to 8, 16:9 or 9:16, each side 320–3840 px |
| Tablet screenshots | Required only if you declare tablet support |
| Category, contact email | Email is public on the listing |
Step 4 — Policy declarations
- Privacy policy URL. Required for every app, even one that collects nothing. Host it anywhere public.
- App access. Whether any part needs a login; if so, provide test credentials for the reviewer.
- Ads. Declare whether the app shows ads.
- Content rating. A questionnaire; a content app is usually "Everyone".
- Target audience. Age groups; choosing under-13 triggers the Families policy, which is much stricter — avoid it unless the app is for children.
- Data safety. What the app collects and shares. A bundled WebView app with no analytics collects nothing; if your pages call an API or load analytics, declare that.
- Government apps, financial features, health — usually "no".
Step 5 — Upload and test
Testing → Closed testing → Create release: upload the AAB, accept Play App Signing when offered, write release notes, add testers by email or a Google Group, and roll out. Testers install from a link you share. For a new personal account this is the mandatory 14-day, 12-tester phase; for others it is optional but wise — it catches a wrong package name or a missing permission before the public does. Internal testing (up to 100 testers, no review) is faster for your own checks.
Step 6 — Production and review
Promote the tested release to production, or create a production release, and submit. Review takes one to three days for a first app, occasionally longer. What reviewers check on a WebView app:
- Minimum functionality. The app must do something. A bundled site with real content, offline use, a proper icon and navigation passes; a single page saying "visit our website" does not.
- Metadata accuracy. Screenshots show the app, the description describes it, no misleading claims.
- Privacy and data safety consistency. The policy and the declarations match what the app does.
- Impersonation and intellectual property. The app is not a copy of someone else's brand, and any content it bundles is yours to distribute.
- Crashes and blank screens. Test on file:// first; the blank-screen guide.
A rejection comes with the policy cited and usually a screenshot. Fix, increment the versionCode, upload, resubmit — there is no penalty for a first rejection.
After launch
Updates are the same upload with a higher versionCode; the updating guide. Play sends policy-change emails several times a year; each new target-SDK requirement is handled by the builder, but you must rebuild and re-upload to get it. Keep the keystore.
Checklist
- Pro AAB signed with your keystore; keystore backed up
- Developer account verified; 14-day closed test scheduled if required
- Icon 512, feature graphic 1024 × 500, 2+ screenshots
- Privacy policy URL live
- Content rating, data safety, target audience completed
- Play App Signing accepted
- App opens to real content offline