Quick answer: Google Play only accepts new apps as Android App Bundles, so a website destined for Play is built as an AAB — same content, different output target — and signed with an upload key under Play App Signing. Before uploading you need a permanent package name, a version code, a 512 px opaque icon, screenshots, a privacy policy URL and the data-safety and content-rating forms, and the app must do more than a browser bookmark would.
1. Build a bundle instead of a package
Nothing in your HTML changes. The build target does: bundleRelease instead of assembleRelease in Gradle, or the AAB option in a build service. Where the APK packed every device's resources into one file, the bundle keeps them separate for Play to split per device.
2. Understand who signs what
With a bundle, Play builds and signs the APKs users install, so it holds a key of its own:
- you sign the bundle with your upload key;
- Play checks it, then signs the generated APKs with the app signing key;
- a lost upload key can be reset by Google — a real improvement on the old model.
Back up the upload key and its password somewhere that outlives your current laptop. A password manager entry is better than a file.
3. Fix the identifiers before the first upload
These are checked at upload, and one of them can never be changed.
- Package name — permanent, lowercase, reverse-domain, not
com.example. See the package name rules. - Version code — higher than anything you have uploaded before, test tracks included. See versionCode vs versionName.
- Target SDK — Play sets a minimum target API level for new submissions and raises it yearly. A build service keeps up; a hand-built project is on you.
4. Gather the listing assets
| Asset | Spec |
|---|---|
| Store icon | 512 × 512 PNG, 32-bit, no transparency |
| Feature graphic | 1024 × 500 |
| Phone screenshots | 2 to 8 |
| Short description | 80 characters |
| Full description | 4,000 characters |
| Privacy policy | A public, working URL |
| Data safety form | What the app (and your website) collects and shares |
| Content rating | A questionnaire — answer honestly |
5. Clear the minimum-functionality bar
This is the policy that rejects converted websites. A WebView pointed at a URL with nothing a bookmark could not do can be turned down as a repackaged site. What moves an app past it:
- Bundled content that works offline;
- push notifications with genuine value;
- native navigation — tabs, a real back stack, a splash screen;
- device features — camera, location, file handling;
- no browser chrome — no URL bar, no "open in browser" prompts.
And you must own or have rights to the content. Wrapping someone else's site is rejected and reported.
6. Upload to a test track first
Create the app in Play Console, upload the AAB to internal testing, and install what Play serves — not what you built. That is the only way to catch a problem introduced by the split itself. Review for a new developer account often takes a few days, and first submissions get a closer look.