Trusted Web Activity availability

Trusted Web Activity (TWA) is, per Chrome’s documentation, “a new way to open your web-app content such as your Progressive Web App (PWA) from your Android app using a protocol based on Custom Tabs.” Chrome’s quick-start guide puts the effect plainly: you can use a Trusted Web Activity “to launch a full screen browser tab, without any browser UI” — a capability “restricted to websites that you own,” where you “prove ownership by setting up Digital Asset Links.”

Browser & ecosystem support

• Legend
• Yes
• Partial
• Flag
• No
• Unknown

Browser / Platform	Support	Versions	Confidence	Source	Notes
Chrome (Android)	Yes	72	medium	source	123

1. Per Chrome's documentation, Trusted Web Activity is available in Chrome on Android from version 72.
2. No cross-browser compatibility dataset (BCD/caniuse) covers TWA; version verified from Chrome's own documentation.
3. The same documentation notes other browsers may implement the same protocol, but does not itself document TWA support in any other browser.

Source data: /compatibility/twa.json · Global usage: 64 % (StatCounter 2026-05)

Source: spec · Last verified 2026-09-09 · Confidence: medium (computed from sources)

Chrome’s overview states that “Trusted Web Activity is available in Chrome on Android, version 72 and above.” It adds that “it is also possible for other browsers to implement the same protocol that Trusted Web activities use,” and that where the host app has the final say on which browser opens, Chrome’s documentation recommends “the same policy as for Custom Tabs: use the user’s default browser, so long as that browser provides the required capabilities.”

Two properties of the model follow from the content coming from the web. Per the overview, the content “rendered in a Trusted Web Activity comes from the web: they’re rendered by the user’s browser, in exactly the same way as a user would see it in their browser except they are run fullscreen.” And because browsers update independently of Android and of your app, that “saves on APK size and ensures you can use a modern web runtime.”

How to use it

Chrome’s quick-start guide uses Bubblewrap, “a set of libraries and a command line tool (CLI) for Node.js that helps developers generate, build and run Progressive Web Apps inside Android applications, using Trusted Web Activity.” It reads your web app manifest, confirms the values to use in the Android project, and generates it:

npm i -g @bubblewrap/cli
bubblewrap init --manifest=https://my-twa.com/manifest.json
bubblewrap build
bubblewrap install

Per the guide, bubblewrap build outputs app-release-signed.apk, a file that “can be installed on a development device for testing or uploaded to the Play Store for release.” bubblewrap install puts it on a connected device; adb install app-release-signed.apk does the same thing.

At this point the guide is explicit that you are not yet in a Trusted Web Activity: “you’ll notice that your website is launched as a Custom Tab, not a Trusted Web Activity. This is because we haven’t set up our Digital Asset Links validation yet.”

Digital Asset Links, per the guide, “consist essentially of a file on your website that points to your app and some metadata in your app that points to your website.” The Digital Asset Links getting-started guide describes that file as a statement list that “is cleartext and publicly accessible, in a location that is controlled by the principal and difficult to spoof or tamper with,” published at https://www.example.com/.well-known/assetlinks.json — “the official name and location for a statement list on a site; statement lists in any other location, or with any other name, are not valid for this site.”

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.app",
    "sha256_cert_fingerprints": ["hash_of_app_certificate"]
  }
}]

Per that guide, each statement “consists of a relation (what the statement says to do) and a target (the website or app that the relation applies to),” and sha256_cert_fingerprints “is the SHA256 fingerprints of your app’s signing certificate.” Chrome’s guide then says to “upload it to your website at .well-known/assetlinks.json relative to the root) so that your app can be verified properly by the browser.”

How to detect it at runtime

The cited Chrome guides do not describe a page-level test for whether the page is running in a Trusted Web Activity. The browser determines that status by verifying Digital Asset Links; if verification fails, it falls back to a Custom Tab. Chrome’s overview separately says that the app and page can coordinate by passing data through URLs, so a query parameter can detect only the marker supplied by the app, not the actual TWA runtime mode. The page must also work when the marker is absent: “Web content should be accessible and useful in the browser first.”

// This tests only an app-supplied URL marker, not whether Digital Asset Links
// verification put the page in TWA mode.
const shell = new URLSearchParams(location.search).get('shell');

if (shell?.toLowerCase() === 'android-app') {
  // A value was passed: use it.
  document.body.dataset.shell = 'android-app';
} else {
  // Nothing was passed. Fall back to the page's own default so the content stays
  // accessible and useful in the browser.
  document.body.dataset.shell = 'default';
}

Practical checklist

• Expect the fallback, and test it. Per Chrome’s quick-start guide, “when you launch a Trusted Web Activity, the browser verifies the Digital Asset Links. If verification fails, the browser falls back to displaying your website as a Custom Tab.”
• Check which signing key you shipped. The guide calls out that “Digital Asset Links take into account the key that an APK has been signed with and a common cause for verification failing is to use the wrong signature,” and warns that “when you publish your app in Google Play, another key may be created for you, depending on how you choose to handle signing keys.”
• Confirm which browser actually answered. Per the guide, a TWA “will try to adhere to the user’s default choice of browser. If the user’s default browser supports Trusted Web Activities, it will be launched. Failing that, if any installed browser supports Trusted Web Activities, it will be chosen. Finally, the default behavior is to fall back to a Custom Tabs mode.” The guide’s own check is adb logcat -v brief | grep -e TWAProviderPicker.
• Know which way the boundary blocks. Per the overview, “the host app doesn’t have direct access to web content in a Trusted Web Activity or any other kind of web state, like cookies and localStorage” — coordination goes through URLs instead.
• Keep an eye on an old Chrome, too: per the overview, “if the user’s version of Chrome doesn’t support Trusted Web activities, Chrome will fall back to a simple toolbar using a Custom Tab.”
• Keep the site installable on its own merits. The overview notes there are “currently no qualifications for content opened in the preview of Trusted Web activities,” but that “you can expect, however, that Trusted Web activities will need to meet the same Add to Home Screen requirements.”
• Remember where the seams are: per the overview, “transitions between web and native content are between activities,” and each screen of the app “is either completely provided by the web, or by an Android activity.”

Where to go next

• Trusted Web Activity (TWA): PWAs in the Play Store
• WebAPK
• Installability criteria — the overview says to expect that Trusted Web activities “will need to meet the same Add to Home Screen requirements.”

← Back to the Compatibility explorer.