Quick Answer
A Trusted Web Activity (TWA) gets rejected on Google Play primarily because Digital Asset Links verification fails — usually a SHA-256 fingerprint mismatch between your assetlinks.json and Google Play App Signing. The fix: include both your Upload Key SHA-256 and the Play App Signing SHA-256 in the sha256_cert_fingerprints array, host the file at https://yourdomain.com/.well-known/assetlinks.json, then verify with Google's Statement List API.
Publishing a Progressive Web App (PWA) as an Android App using Trusted Web Activity (TWA) is one of the fastest ways to hit the Play Store. Tools like Bubblewrap and PWABuilder make converting your website into an Android App Bundle (.aab) feel effortless.
However, TWA apps face double scrutiny from Google Play's automated review bots. Not only must they pass general Android Play Policies, but they must also satisfy strict Digital Asset Links domain verification, Webview / Minimum Functionality policies, and the mandatory 12 testers for 14 days closed testing rule for new personal developer accounts created after November 13, 2023.
If your TWA app was rejected or displays an unexpected browser URL bar inside the app, do not panic. In this 2026 technical guide, we break down every cause of TWA app rejections and provide exact code snippets, fingerprint configuration fixes, and testing strategies to guarantee your production approval.
Essential Reading
The 5 Documented Reasons TWA Apps Get Rejected on Google Play
When Google reviews a TWA submission, it tests both the native Android wrapper and the underlying web application. Rejections fall into one of these five categories — each documented in Google's own developer policy and developer forum threads.
Digital Asset Links Failure (Address Bar Showing)
A TWA is meant to run full-screen, indistinguishable from a native app. If Google's review bot opens your app and sees a Chrome URL address bar at the top, it instantly fails review. This means Google Custom Tabs could not verify digital ownership between your Android app package and your web domain. The most common cause is a SHA-256 fingerprint mismatch.
Webview Minimum Functionality Policy Violation
Google Play Policy states that an app must provide a valuable user experience beyond simply framing a website. If your website lacks an offline Service Worker fallback, fails when disconnected from the internet, or behaves like a basic blog without interactive app-like UI, Google rejects it under the "Repetitive Content or Minimum Functionality" policy.
OAuth Sign-In Redirecting Out of the App
If your web app uses "Google Sign-In" or third-party OAuth, clicking "Login" might trigger a redirect that opens Google Chrome outside the TWA container. Google Play reviewers consider an app broken if core navigation unexpectedly kicks the user out to an external web browser.
"Insufficient Testing Activity" in Closed Testing
Just like native Java, Kotlin, or Flutter apps, TWAs published on personal developer accounts created after Nov 13, 2023, must pass the 12 testers for 14 days closed testing phase. If your testers don't actively engage with the TWA, Google rejects production access with a "More testing required" notice.
Package Name Mismatch or Missing App Identity
If your twa-manifest.json applicationId does not match the package name registered in Google Play Console, or if the SHA-256 fingerprint in assetlinks.json references the wrong package_name, Digital Asset Links verification silently fails.
Fix #1: Digital Asset Links & SHA-256 Fingerprint Verification
The most common technical error for TWAs is misconfiguring assetlinks.json. For a TWA to hide the Chrome URL bar and run full-screen, your website must host a valid JSON file proving ownership of the Android app.
"An address bar appears inside a Trusted Web Activity when Digital Asset Links verification fails — most commonly when the SHA-256 fingerprint does not match the Google Play App Signing certificate."
— Google Chrome TWA Documentation
Step 1: Host the File at the Correct HTTPS Path
Your server must serve the file at this exact location with an application/json Content-Type header, served over HTTPS with no redirects:
Step 2: Correct assetlinks.json Code Structure
Copy and paste this exact structure into your assetlinks.json file. You must include both SHA-256 fingerprints in the array — your local Upload Key and the Play App Signing Key:
Crucial Mistake: The Double Fingerprint Trap
When you build your TWA with Bubblewrap, it uses your local Upload Key SHA-256 fingerprint. However, when you upload your .aab to Google Play, Google Play App Signing re-signs your app with a different production key.
You MUST include BOTH SHA-256 fingerprints in your assetlinks.json array (your local Upload key AND the App Signing key found in Play Console → Setup → App signing). Otherwise, the app works fine on your local phone during debugging, but shows the browser address bar during Google's review.
Step 3: Find Your Play App Signing SHA-256 Fingerprint
Navigate to Google Play Console → Setup → App signing. The "App signing key certificate" section displays your SHA-256 certificate fingerprint. Copy this value (colons and all) and add it to your sha256_cert_fingerprints array.
Step 4: Verify Asset Links Live Using Google's API
Test your domain using Google's official Digital Asset Links Statement List API. This is the same tool Google's own engineers use to verify TWA setups:
A successful response returns a statements array containing your package name and fingerprints. If the response is empty, your file is unreachable, malformed, or the fingerprint is wrong.
Fix #2: Webview Minimum Functionality Policy
Google Play Policy explicitly states: "We do not allow apps that simply frame a website without providing unique value." To prevent your TWA from getting flagged as low quality, apply these fixes:
- Implement an offline Service Worker: Your PWA must cache static assets (HTML, CSS, JS, icons). If a reviewer turns on Airplane Mode while testing your TWA, it must render a styled offline screen or cached app UI — not the browser's "No Internet" dinosaur page.
- Hide web navigation elements inside the TWA: Hide website footers, global domain header navigation, and desktop sign-in bars when rendering inside the TWA container. Use the
display-mode: standalonemedia query:@media (display-mode: standalone) { /* Hide web-only headers/footers inside the Android TWA app */ .website-header, .website-footer { display: none !important; } } - Handle Android back button navigation: Pressing the physical Android back button must navigate backward in your web app history rather than immediately closing the TWA. Bubblewrap handles this by default in
twa-manifest.json:"enableSiteSettingsShortcut": true, "fallbackType": "customtabs"
Fix #3: OAuth Sign-In Redirecting Out of the App
If your TWA uses Google Sign-In, Facebook Login, or any third-party OAuth flow, configure it to resolve inside the Custom Tab container rather than opening an external browser window. Otherwise Google Play review flags the app as broken.
- Use the Google Identity Services library with FedCM (Federated Credential Management) for modern Chrome support.
- Set
login_uriandredirect_urito URLs that resolve on your own domain — never toaccounts.google.comdirectly. - Test in incognito mode to ensure the OAuth popup does not get blocked by Chrome's popup blocker inside the TWA.
Fix #4: TWAs and the 12 Testers for 14 Days Rule
A very common misconception among web developers is thinking that because TWAs are wrappers for web applications, they bypass Android's testing requirements. They do not.
If you created a new personal Google Play Developer account after November 13, 2023, your TWA app is subject to the exact same Google Play closed testing 12 testers 14 days requirement as native Kotlin or C++ games.
| Testing Component | Native App (.apk / .aab) | TWA Web App (.aab) |
|---|---|---|
| 12 Testers Required? | Yes (Personal Accounts) | Yes (Personal Accounts) |
| 14 Continuous Days? | Yes | Yes |
| Telemetry Tracked | ANR, Crashes, Daily Sessions | Play Integrity, Custom Tab Sessions, Vitals |
| Rejection Risk | High if testers don't engage | High if assetlinks fails or silent testers |
If your 12 testers do not open the TWA app regularly during the 14 days, Google will reject your production application with the notice "More testing required to access Google Play Production".
Fix #5: Complete Resubmission Blueprint
Follow this clean, sequential blueprint to resolve all TWA rejection strikes and reapply for production access confidently:
Clean Your assetlinks.json
Ensure your .well-known/assetlinks.json contains SHA-256 fingerprints for BOTH your local Upload key and Google Play App Signing key. Test it using Google's API Statement tool.
Deploy Service Worker Caching
Update your PWA Service Worker to serve an offline fallback page so reviewers never see a connection error screen.
Re-build AAB with Bubblewrap / PWABuilder
Recompile your TWA project bundle with updated version codes (e.g., bump versionCode from 1 to 2 in build.gradle) and upload to the Closed Testing track.
Enroll 12 Verified Human Testers
Add 12 real testers on physical Android devices. Ensure they open the TWA daily to generate authentic session data across the 14 continuous days.
Submit Production Access Form
Fill out the final production access questionnaire detailing how you verified web assets, fixed navigation bugs, and gathered feedback during testing.
Frequently Asked Questions
An address bar appears inside a Trusted Web Activity when Digital Asset Links verification fails. Common causes: assetlinks.json is missing from /.well-known/, the file is hosted on HTTP instead of HTTPS, the file has invalid JSON syntax, or — most commonly — the SHA-256 fingerprint in assetlinks.json does not match Google Play App Signing (instead of your local Upload Key). The TWA then falls back to Chrome Custom Tabs which displays the URL bar.
Yes. Any app — including TWA, PWA, native, or hybrid — published on a personal Google Play Developer account created after November 13, 2023 must complete 12 testers for 14 continuous days of closed testing before production access is granted. TWA apps are not exempt because they are distributed as Android App Bundles (.aab) and run on the device through Chrome.
Google rejects TWAs under the Minimum Functionality policy if the web app behaves like a static webpage, lacks an offline Service Worker fallback, fails to load when disconnected from the internet, redirects users out to an external browser window, or simply frames a website without providing app-like value.
Open Google Play Console → Setup → App signing. The App signing key certificate section displays your SHA-256 certificate fingerprint. Copy this value (and optionally your Upload Key fingerprint) into the sha256_cert_fingerprints array inside your assetlinks.json file.
Yes, but OAuth must be configured with cross-origin headers and must not redirect the user out of the Custom Tab container. Use the Google Identity Services library with FedCM or proper OAuth callback URLs that resolve inside the TWA. Otherwise, the sign-in flow breaks app review and triggers a policy violation.
Standard TWA app reviews typically take 3 to 7 days. First-time developer accounts on the 12 testers for 14 days closed testing track require the full 14 days of testing before production review begins, plus 3 to 7 additional days for production review — a total of roughly 17 to 21 days from first upload to production approval.
A PWA (Progressive Web App) runs entirely in a web browser using Service Workers, manifests, and HTTPS. A TWA (Trusted Web Activity) is an Android wrapper built with Bubblewrap or PWABuilder that packages a PWA as an installable Android App Bundle (.aab) for Google Play. TWAs hide the browser UI and require Digital Asset Links verification, while PWAs are accessed via URL.
Need 12 Real Testers for Your TWA App?
Setting up your TWA's assetlinks.json is only half the battle. Passing Google's 14-day closed testing requirement requires 12 real people on physical Android devices using your web app daily.
Do not risk getting rejected for "insufficient testing activity". Our service provides 12+ verified human testers who actively test your TWA for 14 continuous days, guaranteeing 100% production access approval.
Last updated: August 12, 2026 — Fact-checked against current Google Play Policy and Chrome TWA documentation