1.1 API 定位:Android 设备可信身份认证层

Play Integrity API 是 Google 提供的云端验证服务,用于帮助开发者确认应用正运行在未经篡改的 Android 设备上,且由官方渠道分发。它取代了传统的 SafetyNet Attestation API,成为 Android 设备“可信身份”的核心认证层。

API 定位:Play Integrity API 不是本地 SDK,而是一种“请求‑验证‑响应”的远程认证协议。应用向 Google Play 服务发送加密令牌,Google 服务器返回实时的设备、应用和用户状态报告。

1.1.1 核心能力矩阵

能力 描述 典型判断
设备认证 验证设备是否通过 Google 认证、未被 root、未运行模拟器或自定义 ROM。 deviceIntegrity 字段:MEETS_DEVICE_INTEGRITY / LACKS_INTEGRITY
应用完整性 验证应用包名、签名证书是否与 Play 商店上架版本一致,防止重打包。 appRecognitionVerdict 字段:PLAY_RECOGNIZED / UNRECOGNIZED_VERSION
用户许可 验证用户 Google 账号是否合法(非受控设备、非测试账号),并确认用户同意 Play 协议。 accountDetails 中的 appLicensingVerdict:LICENSED / UNLICENSED

1.1.2 与传统 SafetyNet 的对比

对比维度 SafetyNet Attestation Play Integrity API
验证协议 基于非对称加密的离线验证(通过 Google 公钥自行解析) 云端实时验证,服务器直接返回结构化 JSON
用户许可 无:只判断设备和应用签名 有:新增账号许可检查(防止盗版/共享账号)
重放攻击防护 需开发者自行管理 nonce 和过期时间 内置请求随机数和过期窗口(默认 5 分钟)
模拟器检测 通过 ctsProfileMatch 弱判断 直接提供 MEETS_DEVICE_INTEGRITY 细粒度状态
推荐迁移 已标记为弃用(2024 年后停止服务) 当前及未来的官方首选方案
迁移提示:如果应用仍在使用 SafetyNet,应尽快在 2024 年底前迁移至 Play Integrity API。两者请求流程相似,但响应字段和验证逻辑需重写服务器端解析。

1.1.3 工作原理总览

下图展示了 Play Integrity API 的完整验证流程及三个核心能力的分布关系:

Play Integrity API 工作原理与核心能力 Play Integrity API 工作原理与核心能力 Android 应用 Google Play 服务 Google 云端服务器 令牌请求 (nonce) 令牌 + 签名 设备认证 (Device Integrity) 应用完整性 (App Recognition) 用户许可 (Account Licensing) ⚠️ 与 SafetyNet 的主要区别 • 在线验证 vs. 离线验证  • 增加用户许可字段  • 内置 nonce/过期保护  • 细粒度模拟器检测 • SafetyNet 已于 2024 年停止服务,所有应用应迁移至 Play Integrity API

1.1.4 典型验证响应示例

Play Integrity API 返回的 JSON 包含三个顶层字段,分别对应三大核心能力:

{
  "requestDetails": {
    "requestPackageName": "com.example.app",
    "nonce": "f1a2b3c4d5e6",
    "timestampMillis": "1700000000000"
  },
  "appIntegrity": {
    "appRecognitionVerdict": "PLAY_RECOGNIZED",
    "packageName": "com.example.app",
    "certificateSha256Digest": ["..."],
    "versionCode": 123
  },
  "deviceIntegrity": {
    "deviceRecognitionVerdict": ["MEETS_DEVICE_INTEGRITY"],
    "deviceAttributes": {
      "hasBootloaderUnlock": false,
      "hasRoot": false
    }
  },
  "accountDetails": {
    "appLicensingVerdict": "LICENSED"
  }
}
注意:不要将原始 JSON 直接返回给客户端。服务器应在解码并验证签名后,仅将通过/失败状态传递给应用,避免泄露令牌或设备细节。

1.1.5 开发者决策流程

  1. 检查设备完整性:若 deviceIntegrity.deviceRecognitionVerdict 包含 MEETS_DEVICE_INTEGRITY,则通过;否则拒绝高风险操作。
  2. 检查应用完整性:若 appIntegrity.appRecognitionVerdict 为 PLAY_RECOGNIZED,则确认应用未被篡改。
  3. 检查用户许可:若 accountDetails.appLicensingVerdict 为 LICENSED,则允许正常使用;UNLICENSED 可引导购买或退出。
  4. 综合判定:通常三个条件全部满足才视为“可信”环境,但可根据业务场景放宽(例如仅检查设备和应用,忽略账号许可)。
性能建议:每次验证请求会产生网络开销(约 200‑500ms)。建议在关键操作(支付、登录、高级内容解锁)时触发,而非每个页面都调用。可缓存验证结果 5‑10 分钟(配合 nonce 刷新)。