Yes, you can publish a PWA on Google Play. You wrap the PWA in a Trusted Web Activity (TWA), a small Android app that opens your site full screen in Chrome, then prove you own the site with an assetlinks.json file and upload the resulting AAB in Play Console. Google’s own tool for this is Bubblewrap, and the app goes through the same review as any other Android app.
How a PWA gets onto Google Play
A PWA reaches Google Play inside a Trusted Web Activity, because Play only accepts Android packages, not web addresses. The Android TWA overview describes a TWA as a way to open your web app with a protocol based on Custom Tabs. Chrome draws the page; your app is just the launcher around it.
Two things make this work:
- A package. Bubblewrap reads your web app manifest and creates the packages, APK or AAB, that you upload to Google Play, per Google’s PWA in Play guide.
- Proof of ownership. Digital Asset Links connect the app and the site. If Chrome can’t verify that link, the app still opens, but with a browser toolbar on top.
The same overview notes TWAs need Chrome on Android version 72 and above. On a phone with no supported browser, the page falls back to a Custom Tab.
What you need before you start
You need a site you control and the tools to build the wrapper. The domain is the part a build tool can’t fix for you.
- A working PWA on HTTPS with a web app manifest that has a name, icons and a start URL.
- Control of the domain, so you can host a file at
/.well-known/assetlinks.json. - Node.js 10 or higher. The Chrome quick start lists it, and Bubblewrap offers to download the JDK and Android command line tools for you.
- A Google Play developer account. The fee and verification steps are covered in how much it costs to publish on Google Play.
- A privacy policy URL and store screenshots for the listing.
How to publish a PWA on Google Play, step by step
Build the wrapper with Bubblewrap, host the asset links file, upload the AAB to a testing track, then promote it to production.
- Install Bubblewrap. Run
npm i -g @bubblewrap/cli. - Create the project. Run
bubblewrap init --manifest=https://your-site.com/manifest.json. It asks for the package name, app name, colours and signing key details. Write down the key password. - Build. Run
bubblewrap build. The quick start says this outputsapp-release-signed.apkfor testing, and the Web In Play release notes add that Bubblewrap now packages an App Bundle calledapp-release-bundle.aab. The AAB is what Play wants. - Get your fingerprint. Google’s guide says Bubblewrap no longer writes the Digital Asset Links file for you. Use its
fingerprintcommand to produce the SHA-256 entry. - Host the file. Upload
assetlinks.jsonto.well-known/assetlinks.jsonat the root of your domain. - Test on a phone.
bubblewrap installputs the APK on a connected device. Open it and check there’s no address bar. - Upload to a testing track. Google recommends first releasing to a testing track with a trusted testers list. New personal developer accounts also face a closed testing requirement before production.
- Add the Play signing fingerprint (next section), then promote the release.
Why the address bar comes back after Play publishes it
The address bar usually returns because Google Play re-signs your app with a different key than the one you tested with. A Bubblewrap issue thread explains it: with Play App Signing on, the store re-signs the package, so the SHA-256 fingerprint of the copy users download is different.
Your assetlinks.json then lists only your upload key, Chrome fails verification, and users see a toolbar even though your local test, signed with your own key, had none.
Copy the app signing key’s SHA-256 from Play Console and add it to the sha256_cert_fingerprints list next to your own. If the two keys confuse you, upload key vs app signing key walks through which is which, and what Play App Signing is covers why Google holds one of them.
Rules that decide whether the app launches well
Google Play reviews a packaged PWA like any Android app, and a few rules hit PWAs harder than native apps.
| Rule | What it means for a PWA |
|---|---|
| Ownership | Play’s spam policy bans apps that provide a webview of a website without permission from the website owner or administrator. |
| Quality criteria | Since Chrome 86, the app must handle a failed asset links check at launch, return HTTP 200 for offline requests, and avoid 404 or 5xx errors. |
| Payments | Digital goods under the Play payments policy need Play billing before launch, according to Google’s guide. |
| Pricing | Google does not recommend the paid app option, since the same PWA is still reachable in the browser. |
| Updates | Rebuild when you change manifest icons or theme color, or when the app is over a year old. |
The offline rule is the easiest one to miss. If your service worker lets a request fail with no fallback page, the app breaks the criteria the first time someone opens it in a lift. Add an offline page to your cache before you submit.
When a Trusted Web Activity is the wrong tool
A TWA is the right way to publish a PWA on Google Play only when you own the site and it already works well in Chrome. It is the wrong tool for a site you can’t put files on, or for content that must work offline from the first launch.
A small shop on a hosted site builder can’t upload .well-known/assetlinks.json, so a TWA would always show the toolbar. A WebView app is the usual answer there; PWA vs WebView app covers the trade-offs.
WebToAPK Free builds that kind of WebView app in the browser. It packages a hosted HTTPS site, self-contained HTML or text pages and signs the APK and AAB locally, without uploading your key. Its limits matter here: it doesn’t do push notifications, apps need Android 8.0 or newer, and an AAB from it is not Play approval. The website to APK guide shows the steps.
My take: if you own the domain and the PWA passes in Chrome, use Bubblewrap. A TWA shares the user’s Chrome logins and gets every web feature. Pick a WebView build only when one of the limits above rules the TWA out.
FAQ
Do I need to rebuild the Play app every time my PWA changes?
No. The app loads your live site, so content and code changes reach users without a new release. You rebuild when you change the web app manifest, such as icons or theme color, or when the app is over a year old and needs the latest Android SDK.
Why does my published PWA show a browser address bar?
Chrome could not verify that your app and site belong together. After Play App Signing re-signs the app, its SHA-256 fingerprint changes, so assetlinks.json must list the Play signing key’s fingerprint as well as your own.
Can I charge for a PWA on Google Play?
Google does not recommend the paid app option for PWAs, because the same PWA is still reachable in the browser. It suggests in-app purchases or subscriptions, and digital goods covered by the Play payments policy need Play billing before launch.
Can I publish someone else’s website as a PWA app?
No. A Trusted Web Activity only works full screen on a site you can verify with Digital Asset Links, and Play’s spam policy bans apps that show a website without permission from its owner.