Google 的 Play Integrity API 替代 SafetyNet，设备认证兼容性

Google 的 Play Integrity API 替代 SafetyNet，设备认证兼容性

2024 年初，SafetyNet Attestation API 彻底停止响应。对那些还在客户端里直接解析 ctsProfileMatch 和 basicIntegrity 的老旧代码来说，这不是一个平滑过渡，而是一次强制断电。很多开发者直到收到 Google Play Console 的迁移警告邮件，才意识到原来那个返回 JSON 字符串、可以在客户端直接判断真伪的 SafetyNet，已经被一个加密的、必须经服务端二次验签的 Play Integrity Token 所取代。更麻烦的是，这次替换带来的兼容性冲击，远比 Google 官方文档里那句"无缝迁移"要血腥得多。

SafetyNet 的强制下线与 Play Integrity 的仓促接棒

SafetyNet 从 2013 年前后推出，到 2024 年彻底关闭，活了十年出头。它最初的设计意图很简单：让开发者能区分一台设备是"经过 Google 认证的 Android 设备"还是"被篡改过的玩具"。早期它返回一个清晰的 JSON，里面两个布尔值最关键：ctsProfileMatch 表示这台机子是否通过了兼容性测试套件（CTS），basicIntegrity 表示设备是否存在明显的系统级篡改。很多中小开发者甚至直接在 App 客户端里判断这两个字段，虽然这违背了 Google 自己的安全建议——因为客户端校验根！本！没！用！——但架不住实现成本极低，调个 Google Play Services 的 API，解析个 JSON，五分钟就能集成完。

Google 在 2022 年年中宣布 SafetyNet 进入弃用流程，给出的理由是它的客户端响应容易被中间人攻击和伪造，且无法有效应对越来越复杂的 root 方案。替代者 Play Integrity API 在架构上确实更严谨：客户端向 Google Play 服务请求一个一次性的加密令牌（token），这个 token 是加密的，客户端无法解读；随后必须由开发者的后端服务器拿着这个 token，再去调用 Google Play Developer API 进行解密和验证。Google 的愿景是建立一个端到端的信任链，让客户端无从伪造。

问题出在时间线和迁移策略上。Google 给了一年半的缓冲期，听起来充裕，但对于已经深度依赖 SafetyNet 的存量应用，这几乎意味着要重写整个设备认证的后端链路。SafetyNet 的响应可以在客户端即时得到结果，很多应用的业务逻辑（比如是否显示支付入口、是否允许登录）高度耦合在这个同步调用里。切换到 Play Integrity 后，必须异步走一趟服务器，延迟增加了，架构复杂度翻倍了，而且对于那些没有后端服务器的纯客户端应用——比如某些独立开发者的单机