App Links怎么配置？ 在 Android 生态中，App Links 是谷歌基于 HTTPS 深度链接推出的官方应用链接标准，允许系统在验证域名归属后，直接使用 App 打开网页对应内容，而不再弹出“使用哪个应用打开”的系统选择框。要成功配置 App Links，开发者必须同时完成两部分工作：第一，在 AndroidManifest.xml 中为目标 Activity 配置带有 android:autoVerify="true" 的 intent-filter；第二，在网站根目录下的 .well-known 路径部署 assetlinks.json 文件，让 Android 系统验证 App 与域名之间的可信绑定关系。只有这两步全部完成，并且签名、包名、域名、路径规则完全一致，系统才会把对应的 HTTPS 链接视为“已验证的应用链接”，并默认交给你的 App 处理。

如果把早期的 Deep Link 看作“我声明我能处理这个链接”，那么 App Links 就是“系统确认这条链接确实归我所有”。这两者虽然表面上都能实现从网页跳到 App，但底层的信任模型完全不同。普通 Deep Link 依赖的是客户端单方面声明，系统会保留怀疑态度，因此常常弹出选择框；而 App Links 依赖的是 Android 的域名验证机制，属于带有官方背书的信任链路，所以验证通过后可以直接拉起 App。也正因为如此，App Links 被认为是 Android 侧对标 iOS Universal Links 的标准方案，是现代 H5 导流、一键拉起、搜索结果直达、App 内承接的重要技术基础。关于双端拉起体系的整体理解，也可以结合站内文章 一键拉起 一键拉起App怎么做 跨端无缝跳转与场景还原原理解析 一起看。

不过，Android App Links 的实际落地远不像“在清单文件里加一行配置”那么简单。很多团队明明配了 HTTPS 链接，也加了 autoVerify，最后却发现点击链接依然弹出系统选择框，甚至根本没有任何反应。这通常不是 App Links 没用，而是整个校验链条中有某一环失败了：Manifest 规则写错、网站文件位置不对、assetlinks.json 内容不合法、SHA256 证书指纹不匹配，或者服务器做了重定向，都会让系统悄无声息地放弃验证。因此，要真正理解 App Links怎么配置，不能只停留在“怎么写代码”层面，更要看懂它背后的 Intent 路由机制、数字资产链接验证逻辑，以及安卓生态里各种浏览器和 ROM 对标准行为的实际影响。

App Links 是什么

App Links 是 Android 官方在深度链接体系上做的一次升级。它并没有否定 Deep Link 的存在，而是在原有 Deep Link 之上增加了一层“域名所有权验证”，使得系统能更放心地把某个 HTTPS 链接默认交给指定 App 处理。

Deep Link 与 App Links 的概念区别

在 Android 世界里，Deep Link 是一个更大的概念。只要一个链接能够把用户从网页、短信、浏览器或者别的 App 带到你应用内部的某个具体页面，它都可以被称为深度链接。比如自定义 Scheme、普通 HTTPS 链接、甚至某些内部跳转 URI，都属于 Deep Link 的实现形式。

但 App Links 并不是所有 Deep Link 的别名。它有一个很明确的边界：必须是基于 http 或 https 的网页链接，并且已经通过 Android 官方的域名归属验证。也就是说，所有 App Links 都是 Deep Link，但不是所有 Deep Link 都能成为 App Links。普通 Deep Link 更像是一种“开放竞争”的声明，多个 App 都可能声称自己能处理某个链接；而 App Links 则是在系统验证“这个域名确实属于你”之后，给予你的 App 更高优先级乃至默认处理权。这里如果你想先补齐基础概念，可以同时阅读站内文章 URL Scheme URL Scheme怎么打开App 应用内跳转协议原理解析，它更适合理解传统 Scheme 路由的出发点。

为什么 App Links 可以避免系统弹窗

很多开发者第一次接触 App Links 时，最大的感知差异就是：以前点击链接总会弹出一个系统选择框，问你要用浏览器打开还是用某个 App 打开；而配置正确的 App Links 往往可以直接进 App，没有任何额外确认。

这背后的原因并不复杂。Android 系统面对一个普通 Deep Link 时，本质上是中立的。它知道多个应用都可能匹配这个链接，但无法判断谁才是真正“拥有”这个域名的人，所以只能把选择权交给用户。而当 App Links 的验证成功后，系统已经通过 assetlinks.json 明确知道：这个 HTTPS 域名与这个包名、这组签名是可信绑定的。因此，系统不再需要犹豫，也不再需要让用户二选一，而是可以直接把该链接分发给对应 App 处理，从而消除原本影响体验的系统弹窗。

App Links 的底层原理

要真正理解 App Links怎么配置，关键不是背 API，而是要先理解 Android 底层到底是如何识别、校验并分发一条链接的。整个过程大致可以拆成三个阶段：客户端声明处理能力、系统发起域名验证、点击时根据验证结果决定分发给谁。

Intent 过滤器如何声明可处理链接

在 Android 中，所有深度链接能力的起点，都是 intent-filter。当你希望某个 Activity 能够被外部链接唤起时，必须在 AndroidManifest.xml 中为它添加对应的过滤规则。这个规则通常包含以下几个核心部分：

• action 必须声明为 android.intent.action.VIEW，表示这是一个查看型链接请求。
• category 必须包含 android.intent.category.DEFAULT 和 android.intent.category.BROWSABLE，分别表示该页面既能处理普通隐式 Intent，也允许被浏览器或网页外部调用。
• data 用来定义链接的匹配范围，比如 scheme、host、pathPrefix 等。

一个最常见的 App Links 过滤器大致像这样：

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />

    <data
        android:scheme="https"
        android:host="www.example.com"
        android:pathPrefix="/product" />
</intent-filter>

这段配置表达的意思其实很直白：如果外部出现了一个 https://www.example.com/product... 的链接，那么这个 Activity 声称自己可以处理它。注意，这里只是“声明可以处理”，还不等于“已经获得系统默认处理权”。

autoVerify 与域名验证机制怎么工作

android:autoVerify="true" 是 App Links 与普通 Deep Link 最关键的分水岭之一。它告诉 Android 系统：请在安装应用后，主动去验证这个域名是否真的归这款 App 所有。

当用户安装或更新 App 后，系统会读取 Manifest 中所有开启了 autoVerify 的 intent-filter。然后，它会尝试访问这些域名下的标准验证文件地址，也就是：

https://你的域名/.well-known/assetlinks.json

如果系统能够成功访问这个文件，并且发现其中声明的包名与证书签名正好与你当前安装的 App 完全一致，那么验证就通过了。通过之后，系统会把这个域名标记为“已验证的应用链接域名”。此后，用户点击这个域名下、且符合过滤规则的链接时，Android 就可以跳过选择框，直接使用这款 App 打开内容。

如果验证失败，系统通常不会给你一个非常显眼的报错提示，而是悄悄回退为普通 Deep Link 处理逻辑。也就是说，链接可能仍然能打开，但它不会获得“默认直达”的那种高级待遇。这里和 iOS 的设计思路其实很接近，如果你想建立双端统一认知，可以同步看站内文章 Universal Links Universal Links怎么配置 iOS通用链接唤醒原理解析。

assetlinks.json 为什么是关键绑定文件

如果说 Manifest 里的 intent-filter 是 App 在向系统“报名”，那么 assetlinks.json 就是网站域名在向系统“作证”。它本质上属于 Android Digital Asset Links 机制的一部分，是 Android 用来判断“某个域名到底是否信任某个 App”的关键文件。

这个文件必须部署在固定位置：

https://你的域名/.well-known/assetlinks.json

文件内容通常是一个 JSON 数组，其中需要声明至少三件事：

1. 关系类型，一般是表示允许处理全部 URL 的关系。
2. 目标 App 的包名。
3. 对应该 App 签名证书的 SHA256 指纹。

一个典型示例如下：

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.app",
      "sha256_cert_fingerprints": [
        "12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF"
      ]
    }
  }
]

这段声明其实是在告诉 Android 系统：我是 www.example.com 这个域名的所有者，我同意由包名为 com.example.app 且签名指纹为指定值的这个应用，处理我名下的 URL。
因此，assetlinks.json 可以理解为 Android 侧的“所有权证明文件”，作用非常类似于 iOS Universal Links 里的 AASA 文件。如果你前面已经看过 iOS 侧的实现，再来看这里会更容易理解两者的镜像关系，可回看 Universal Links Universal Links怎么配置 iOS通用链接唤醒原理解析。

App Links 的核心配置流程

在真实项目中，App Links 的配置不是某一个人的单兵作战，而是客户端、服务端、运维往往都要一起配合完成的联合工程。下面按最常见的落地流程拆解。

Manifest 配置方法与关键字段

第一步是在 Android 项目中正确配置 Manifest。这里最容易出错的地方，不是语法，而是规则边界没有搞清楚。一个合格的 App Links 配置通常需要注意以下几点：

1. 必须使用 http 或 https
   App Links 不支持自定义 Scheme。如果你写的是 myapp:// 这种形式，那它属于普通 Scheme Deep Link，而不是 App Links。
2. 建议优先使用 https
   虽然 http 也能出现在 Deep Link 配置里，但真正安全、规范且可验证的 App Links 场景，应优先以 HTTPS 为准。
3. host 必须精确声明
   比如你要处理的是 www.example.com，那就写这个域名；如果还需要支持 m.example.com，通常要单独补充规则。
4. 路径范围要适度，不要过窄也不要乱写全开
   如果你的 H5 页面只希望 /product/ 下的链接进入 App，就用 pathPrefix="/product"；如果规则写得太窄，很多实际链接不会命中；写得太宽，又可能误拦截不该进 App 的网页。

一个完整示例如下：

<activity android:name=".ProductDetailActivity">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />

        <data
            android:scheme="https"
            android:host="www.example.com"
            android:pathPrefix="/product" />
    </intent-filter>
</activity>

这里的核心不是代码本身，而是你要明确：Manifest 负责声明“我能接”，但默认还没资格“我来接”。
如果你之前是从 Scheme 方案迁移过来的，这一步尤其容易误判，可以顺手对照 URL Scheme URL Scheme怎么打开App 应用内跳转协议原理解析 看差异。

assetlinks.json 的部署位置与内容结构

第二步是服务器侧配置 assetlinks.json。这是整个 App Links 能否成为“已验证链接”的关键。

文件必须满足以下要求：

• 文件名固定为 assetlinks.json
• 路径固定为 /.well-known/assetlinks.json
• 必须通过 HTTPS 正常访问
• 返回内容必须是合法 JSON
• 内容中声明的包名必须与你 App 的正式包名一致
• 内容中声明的 SHA256 指纹必须与你实际安装包的签名一致

如果你使用 Play App Signing，这里尤其要注意：有时候开发者本地签名和 Google Play 最终分发签名并不是同一个值。假如线上分发包已经切换到了 Play 签名，但 assetlinks.json 里仍然写的是本地 keystore 的 SHA256，那么验证大概率会失败。

因此，在写 assetlinks.json 前，必须先确认你到底要填哪套证书指纹。测试环境、预发环境、正式环境如果使用了不同签名，也要注意不要混淆。

为什么配了 HTTPS 还会弹出系统选择框

这是最常见、也最让人困惑的问题之一。很多开发者会说：我已经把链接改成 HTTPS 了，为什么点击后还是弹出“浏览器还是应用打开”的系统选择框？

答案很直接：因为 HTTPS 不等于 App Links。

HTTPS 只是前提条件，不是验证结果。只有当以下两件事同时成立时，系统才会把它当作“已验证的 App Links”：

1. Manifest 中存在 android:autoVerify="true" 且规则能匹配该链接。
2. 系统成功读取并验证了对应域名下的 assetlinks.json。

只要其中一项失败，这个 HTTPS 链接就仍然只是“一个普通的 Web Deep Link”。它可能还能命中你的 Intent 过滤器，但系统不会默认认为它归你所有，于是依然保留弹出选择框的权利。

方案价值与技术评估矩阵

理解配置细节之后，还要回到业务层面看：为什么 Android App Links 值得做？它对产品、增长和用户体验到底有什么现实价值？

为什么 App Links 是 Android 一键拉起的关键组成

在移动增长场景里，最理想的链路从来不是“用户点开网页，再点按钮，再选应用，再跳详情页”，而是“一点即达”。App Links 的核心价值，就在于它把原本需要用户多做一步确认的过程，尽量提前在系统层解决掉。

它在很多场景里都非常关键：

• H5 导流 App：用户在活动页、商品页、文章页点击链接后，直接进入 App 内对应页面。
• 搜索结果直达：用户在搜索引擎里点开某条结果，如果装了 App，就直接进原生页面，而不是先看网页。
• 短信 / 邮件召回：运营给用户发一条活动链接，用户一点击就能直达 App 内特定活动场景。
• 广告投放承接：落地页内容和 App 内页面实现路径一致，减少转化断层。

因此，App Links 实际上是 Android 侧“一键拉起”方案的标准基础设施之一。如果没有它，很多 H5 与 App 的链路就会卡在系统选择框或浏览器承接这一层，体验会明显折损。这里建议结合站内文章 一键拉起 一键拉起App怎么做 跨端无缝跳转与场景还原原理解析 一起看，会更容易把技术点和业务价值对应起来。

Android 链接方案评估矩阵

为了更清楚地理解 App Links 在整个链接体系中的位置，可以用下面这张表来对比三类常见方案：

从这张表就能看出：App Links 真正的价值，不在于“能不能跳”，而在于“能不能稳定、默认、无确认地跳”。

局限性与常见踩坑

虽然 App Links 是 Android 官方标准，但在真实设备、真实浏览器、真实国内流量环境下，它并不是百分之百完美无缺的。理解它的边界，才能更好地做方案兜底。

为什么某些国产浏览器或超级 App 内仍然不稳定

理论上，App Links 是 Android 官方认可的 HTTPS 应用链接方案，验证通过后应该能获得优先处理权。但现实中，很多国内浏览器、超级 App、甚至某些 ROM 的自带内容容器，并不会完全按照原生 Android 官方标准来执行。

原因通常有几类：

• 宿主应用出于商业目的，优先希望用户停留在自己生态内，而不是跳去别的 App。
• 某些浏览器对外部跳转做了额外拦截或手动确认。
• 某些 ROM 对链接分发策略做了深度定制，导致官方行为被覆盖。
• 某些设备默认浏览器或安全中心会篡改“默认打开应用”的判定逻辑。

因此，哪怕 App Links 在 AOSP 标准环境下已经验证通过，在某些国产浏览器或超级 App 中仍然可能表现得不够稳定。这一点和 iOS 的 Universal Links 很像：标准是标准，生态是生态，真正的落地效果还要看宿主环境愿不愿意配合。要建立更完整的双端视角，也可以参考 Universal Links Universal Links怎么配置 iOS通用链接唤醒原理解析。

如何用 adb 测试 App Links 是否生效

当你怀疑 App Links 没有生效时，不能只靠手点网页猜结果，最好直接用 adb 做显式验证。常见的测试方式有两类。

第一类是直接发起一个查看链接的 Intent：

adb shell am start -W -a android.intent.action.VIEW -d "https://www.example.com/product/1001"

如果系统把这个请求直接分发给你的 App，并成功进入对应页面，说明至少 Intent 过滤规则已经命中。

第二类是验证 App Links 的官方验证状态，常用命令包括重新触发校验或查看结果。例如：

adb shell pm verify-app-links --re-verify com.example.app

然后再配合查看当前系统记录的域名状态。不同 Android 版本命令细节会有差异，但核心思路都是一样的：不要只测“能不能跳”，还要测“系统是否真的把它当成 verified link”。

另外，如果你刚更新了 assetlinks.json，但设备上始终没有效果，也可以通过重新安装 App、清理默认打开设置、重新触发验证来排查，而不要默认认为是代码逻辑本身出错。

常见问题

App Links 和 URL Scheme 能同时存在吗？

可以，而且在很多真实项目里本来就是并存的。App Links 更适合处理标准 HTTPS 链接和网页承接场景，而 URL Scheme 仍然适合某些内部调用、老链路兼容或者第三方特殊协议调起场景。成熟的 App 往往不是“二选一”，而是让多套机制协同存在，再根据场景选择最优链路。这里如果你需要对 Scheme 的作用范围重新建立认知，可以回看 URL Scheme URL Scheme怎么打开App 应用内跳转协议原理解析。

assetlinks.json 修改后为什么不立即生效？

因为系统验证不是每次点链接都实时重新拉取。很多情况下，Android 会在应用安装、更新或特定校验时机缓存结果。如果你刚改完服务器文件就立刻测试，设备可能还在用旧缓存。因此调试时通常需要重新触发校验，必要时卸载重装应用，或者结合 adb 强制重新验证。

App Links 能解决未安装后的安装归因吗？

不能完整解决。App Links 擅长的是“已安装时直接进 App、未安装时平滑打开网页”，但一旦用户从网页跳到应用商店下载安装，中间这段上下文在系统层通常会丢失。也就是说，App Links 能解决一部分跨端承接问题，但不能单独解决完整的安装归因与安装后参数恢复问题。这个问题如果继续往下看，本质就会进入一键拉起与安装后归因体系，可以接着参考 一键拉起 一键拉起App怎么做 跨端无缝跳转与场景还原原理解析。

Android 15 的 Dynamic App Links 是什么方向？

从方向上看，它是在传统 App Links 基础上做更灵活的动态规则控制，让链接行为的调整不必完全依赖重新发版。也就是说，Android 官方正在继续强化“可验证 HTTPS 链接直达 App”这条路线，而不是回到过去那种完全依赖客户端静态声明的 Deep Link 时代。这也说明，App Links 不是过渡方案，而是 Android 官方会持续投入演进的长期标准。