Trusted Web Activity 可用性

发布于 2026-07-16更新于 2026-10-01作者 Carey Gill · 编辑流程

Trusted Web Activity（TWA） 按 Chrome 文档的说法，是“一种从你的 Android 应用打开 Web 应用内容（例如你的渐进式 Web 应用）的新方式，基于 Custom Tabs 的协议”。Chrome 的快速上手指南把效果说得很直白：你可以用 Trusted Web Activity“启动一个全屏浏览器标签页，不带任何浏览器界面”——这项能力“仅限于你自己拥有的网站”，而你要“通过配置 Digital Asset Links 来证明所有权”。

浏览器与生态支持

图例
支持
部分支持
需开启标志
不支持
未知

浏览器 / 平台	支持	版本	置信度	来源	备注
Chrome (Android)	支持	72	中	来源	¹²³

依据 Chrome 文档，Trusted Web Activity 自 Android 版 Chrome 72 起可用。
没有跨浏览器兼容性数据集（BCD / caniuse）收录 TWA；版本号依据 Chrome 自己的文档核对。
同一份文档提到其他浏览器可能实现相同协议，但没有记录任何其他浏览器对 TWA 的支持。

源数据: /compatibility/twa.json · 全球使用占比: 64 % (StatCounter 2026-05)

来源: 规范 · 最近核验 2026-09-09 · 置信度: 中 (由来源计算)

Chrome 的概览页写明“Trusted Web Activity 在 Android 上的 Chrome 72 及以上版本可用”。它还补充说“其他浏览器也有可能实现 Trusted Web Activity 所使用的同一协议”；在最终由宿主应用决定打开哪个浏览器的前提下，Chrome 文档推荐“与 Custom Tabs 相同的策略：使用用户的默认浏览器，只要该浏览器提供所需能力”。

内容来自 Web，这一点带来两个性质。按概览页的说法，“Trusted Web Activity 中渲染的内容来自 Web：它们由用户的浏览器渲染，方式与用户在浏览器中看到的完全一致，只是以全屏方式运行”。又因为浏览器的更新独立于 Android 和你的应用，这“节省了 APK 体积，并确保你可以使用现代的 Web 运行时”。

如何使用

Chrome 的快速上手指南使用 Bubblewrap——“一套面向 Node.js 的库和命令行工具（CLI），帮助开发者使用 Trusted Web Activity 在 Android 应用内生成、构建和运行渐进式 Web 应用”。它会读取你的 Web 应用清单，请开发者确认要在 Android 项目中使用的值，然后生成项目：

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

按该指南，bubblewrap build 会输出 app-release-signed.apk，这个文件“可以安装到开发设备上测试，也可以上传到 Play Store 发布”。bubblewrap install 会把它装到已连接的设备上； adb install app-release-signed.apk 的效果相同。

到这一步，指南明确指出你还没有进入 Trusted Web Activity：“你会注意到你的网站是以 Custom Tab 而不是 Trusted Web Activity 启动的。这是因为我们还没有配置 Digital Asset Links 校验。”

按该指南，Digital Asset Links“本质上由两部分组成：你网站上的一个指向你应用的文件，以及你应用中指向你网站的一些元数据”。Digital Asset Links 的入门指南把那个文件描述为一份声明清单 （statement list），它“是明文且可公开访问的，位于由主体（principal）控制、且难以伪造或篡改的位置”，发布在 https://www.example.com/.well-known/assetlinks.json——“这是站点上声明清单的官方名称和位置；位于任何其他位置、或使用任何其他名称的声明清单，对该站点都是无效的”。

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

按该入门指南，每条声明“由一个 relation（声明要做什么）和一个 target（该 relation 适用的网站或应用）组成”，而 sha256_cert_fingerprints“是你应用签名证书的 SHA256 指纹”。随后 Chrome 的指南说要“把它上传到你网站的 .well-known/assetlinks.json（相对于根目录），这样浏览器才能正确校验你的应用”。

如何在运行时检测

所引用的 Chrome 指南没有说明页面层面的测试方法，来判断页面是否正运行在 Trusted Web Activity 中。浏览器通过校验 Digital Asset Links 来确定该状态；校验失败时会回退到 Custom Tab。Chrome 的概览页另行说明，应用与页面可以通过 URL 传递数据来协作，因此查询参数只能检测应用提供的标记，不能检测实际的 TWA 运行模式。标记不存在时页面也必须可用：“Web 内容应当首先在浏览器中可访问且有用。”

// 这只测试应用提供的 URL 标记，不能测试 Digital Asset Links 校验
// 是否让页面进入了 TWA 模式。
const shell = new URLSearchParams(location.search).get('shell');

if (shell?.toLowerCase() === 'android-app') {
  // 传入了值：使用它。
  document.body.dataset.shell = 'android-app';
} else {
  // 什么都没传入。回退到页面自身的默认行为，让内容在浏览器中保持可访问且有用。
  document.body.dataset.shell = 'default';
}

实践清单

预期回退会发生，并且真的去测它。按 Chrome 快速上手指南：“当你启动 Trusted Web Activity 时，浏览器会校验 Digital Asset Links。如果校验失败，浏览器会回退为以 Custom Tab 显示你的网站。”
核对你实际用了哪个签名密钥。该指南特别指出“Digital Asset Links 会考虑 APK 是用哪个密钥签名的，而校验失败的一个常见原因就是用错了签名”，并提醒“当你在 Google Play 上发布应用时，可能会为你另外创建一个密钥，具体取决于你选择如何处理签名密钥”。
确认究竟是哪个浏览器响应了。按该指南，TWA“会尽量遵循用户的默认浏览器选择。如果用户的默认浏览器支持 Trusted Web Activity，就启动它。否则，如果有任何已安装的浏览器支持 Trusted Web Activity，就选用它。最后，默认行为是回退到 Custom Tabs 模式。“指南自带的检查方式是 adb logcat -v brief | grep -e TWAProviderPicker。
搞清这条边界挡住的是哪个方向。按概览页，“宿主应用无法直接访问 Trusted Web Activity 中的 Web 内容，也无法访问任何其他类型的 Web 状态，例如 cookie 和 localStorage”——协作要走 URL。
也要考虑旧版 Chrome：按概览页，“如果用户的 Chrome 版本不支持 Trusted Web Activity， Chrome 会回退为使用 Custom Tab 的简单工具栏”。
让站点本身保持可安装。概览页提到，“目前对于在 Trusted Web Activity 预览中打开的内容还没有资格要求”，但“你可以预期 Trusted Web Activity 将需要满足同样的『添加到主屏幕』要求”。
记清接缝在哪：按概览页，“Web 与原生内容之间的切换发生在 activity 之间”，应用的每个界面 “要么完全由 Web 提供，要么由一个 Android activity 提供”。

Trusted Web Activity 可用性

浏览器与生态支持

如何使用

如何在运行时检测

实践清单

延伸阅读