Trusted Web Activities explained: your PWA on Google Play without a second codebase

A Trusted Web Activity is Google's answer to "I have a progressive web app; how do I put it on the Play Store?" It is a minimal Android app that opens your web app in the device's Chrome, full-screen, with no browser UI — and Chrome agrees to hide its UI only because you have proven you own the website. This guide explains how it works and how to ship one.

TWA vs WebView wrapper

Both are Android apps that show a website. The difference is in what renders it:

If your site is a PWA, the TWA is the better vehicle. If your site cannot be a PWA (Shopify theme, Wix, Blogger), the WebView route from the Android app builder is the one available.

How trust is established: Digital Asset Links

Chrome will only hide its UI if the website declares that it trusts the app. You do that by hosting a file at https://yourdomain.com/.well-known/assetlinks.json naming the app's package and the SHA-256 fingerprint of the certificate it is signed with:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourdomain.app",
    "sha256_cert_fingerprints": ["12:34:…"]
  }
}]

On launch, Chrome fetches this file and compares the fingerprint to the running app. Match: full-screen. No match: the site opens in a Custom Tab with a visible URL bar — the app still works, but looks like a browser. The two classic failures are hosting the file under a redirect, and using the fingerprint of your upload key when Google Play re-signs the app with its own app signing key. After the first upload, take the fingerprint from Play Console → App signing and put that one in the file (you can list both).

Tooling

• The PWA Builder on this site — tick the Android option and you get a signed TWA test APK and a starter assetlinks.json in the same zip as the manifest and service worker, with no local toolchain. For the AAB Google Play requires, run one of the two tools below against the same manifest.
• Bubblewrap — Google's command-line tool. Reads your manifest, generates an Android project, builds and signs. Needs Node and the Android SDK (it installs the JDK and SDK for you on first run). Best when you want to customise the Android project.
• PWABuilder (Microsoft) — a web UI over Bubblewrap-style packaging with extra options. Also produces Windows and iOS packages of varying usefulness.

All three produce the same kind of app. Choose by how much you want to touch Android tooling.

What the shell can configure

From your manifest: name, icon, theme_color for the status bar, background_color for the splash screen, orientation, display. From the build: package name, version code, the start URL, whether to enable notification delegation (so web push shows as the app's notifications), and fallback behaviour when no supporting browser is installed. There is no native navigation bar — the web app is the whole UI, which is the point.

Payments: the Digital Goods API

Google Play requires Play Billing for digital goods and subscriptions sold in apps distributed through Play. For a TWA, that is done with the Digital Goods API together with the Payment Request API: your web code queries Play for SKUs and prices, launches the Play purchase flow, and receives a token to verify server-side. It only works when the site is running inside the TWA — the same code path in a browser tab uses your normal web checkout. Physical goods and real-world services are exempt and continue to use your web checkout inside the TWA. If you sell nothing digital in-app, you can ignore this section entirely.

Review considerations specific to TWAs

• Minimum functionality. Google's policy targets apps that add nothing to a website. TWAs are designed by Google and start from a stronger position, but a one-page static site can still be refused. Installability, offline support and push are the evidence reviewers look for.
• Consistency. The Play listing screenshots must show the app as it runs in the TWA — full-screen, no browser bar.
• Data safety. Declare what the website collects; the app is the website.
• Login. If your site requires an account, provide test credentials in the review notes so the reviewer can get past the sign-in screen.

Lifecycle after launch

Content and web-app changes ship through your website with no Play release. You release a new AAB only to change the icon, colours or start URL, or to meet Google's annual target-SDK requirement. Keep assetlinks.json hosted permanently: if it disappears, every installed copy reverts to a Custom Tab with a URL bar on next launch.