本教程不教“过检测”，而是解释为什么一个 App 拒绝运行。你会把 Play 许可、应用识别、设备完整性、Play Protect certification 与本地 Root 检测分开记录，并决定是更新组件、恢复厂商签名系统，还是接受该解锁设备不满足服务策略。
你会完成什么#
- 正确读取
MEETS_BASIC_INTEGRITY、MEETS_DEVICE_INTEGRITY、MEETS_STRONG_INTEGRITY与空结果。 - 区分 App → Play Integrity → token → App 后端的责任边界。
- 用官方入口收集认证、构建、补丁、boot 状态与安装来源证据。
- 不使用 keybox/指纹投喂，给出恢复官方状态或使用未修改设备的结论。
先看结论#
| 信号 | 它说明什么 | 它不说明什么 |
|---|---|---|
| 本地 Root detector | 看见文件、包、属性、mount、进程等线索 | 不是 Google attestation，也不能 100% 判定 |
| Play Protect certification | 设备/构建是否通过 Google 认证登记 | 不是恶意软件扫描开关，也不等于目标 App 放行 |
| BASIC | 较低保证的基础环境信号 | 不保证 Bootloader 锁定或厂商镜像 |
| DEVICE | Android 13+ 通常需要硬件证据表明锁定且为认证厂商镜像 | 不代表任何 App 必须接受它 |
| STRONG | DEVICE 之外还要求较新的 OS/vendor 安全更新 | 不是所有 App 默认请求的固定“第三关” |
| 空 verdict | 该标签未满足或请求/环境有问题 | 不能单凭空值断言“就是 Root” |
心智模型#
App → Play Integrity API → 加密 token → App 后端验证 → 业务策略
│ │ │ │
请求参数 Google 信号 防重放/账号/应用 放行、降级或拒绝
本地 detector ── 另一条客户端信号，不等于上述服务端链路SafetyNet Attestation 已在 2022 年 deprecated，并于 2025 年 1 月完全关闭；2026 年继续“测试 SafetyNet”没有当前诊断价值。默认 deviceRecognitionVerdict 主要围绕 DEVICE 或空，BASIC 与 STRONG 是开发者可选择接收的附加标签，不应简化为所有 App 必过的三道关。
工具清单#
| 工具 | 角色 | 什么时候用 | 来源与注意 |
|---|---|---|---|
| Play Store 认证页面 | 查 Play Protect certification | 普通用户第一步 | 和 Play Protect 扫描是不同功能 |
| Play Console test responses | 开发者测试 verdict 分支 | 自有 App 后端 | 使用分级响应和 remediation dialog |
| 系统/fastboot 只读信息 | 查 build、SPL、lock state | 归因设备层 | 属性截图不能替代硬件 attestation |
| 开源本地 detector | 对照本地信号 | 自有测试机 | checker 结果不等于目标服务后端 |
项目全景：Play Integrity / SafetyNet的 7 个项目，一个不漏#
七个项目按“先测量、再理解、后评估修复”组织：检测器给出信号，教程解释 SafetyNet 到 Play Integrity 的变化，修复栈只在合规测试机上评估；历史 SuperSU 签名规避单独标为旧机制。
| 技术路线 | 项目数 | 处理等级 | 在主题任务中的位置 |
|---|---|---|---|
| 检测器与基线诊断 | 2 | 参考/审计 | 先用 kknd_Root_Detector 与 SecurityKit 一类项目区分本地 Root、模拟器、调试和篡改信号。它们不是 Google Play Integrity 裁决本身，结果只用于建立基线。 |
| 完整性修复与隐藏组合栈 | 2 | 参考/审计 | 比较 specter 与 Play-IntegrityFix 等组合栈包含的 Zygisk、属性、证书/Keybox 和自动化层。文章只讲组成、依赖与失败隔离，不分发私钥或承诺 STRONG。 |
| SafetyNet/Play Integrity 教程与政策脉络 | 2 | 参考/审计 | 用两个指南项目解释 DenyList、旧 SafetyNet 术语与银行 App 场景，并要求用当前 Google 文档校正过时内容。教程仓库是经验来源，不是官方政策。 |
| 旧式签名检测与 SuperSU 规避 | 1 | 参考/审计 | 把 supersu-patcher 作为历史案例：重命名二进制可绕过简单签名扫描，但不代表通过现代硬件证明。仅讲演进关系和防守测试价值。 |
1. 检测器与基线诊断 · 2#
先用 kknd_Root_Detector 与 SecurityKit 一类项目区分本地 Root、模拟器、调试和篡改信号。它们不是 Google Play Integrity 裁决本身，结果只用于建立基线。
本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。它们用于对照、诊断或审计，不组成可批量安装的推荐清单。
| 项目 | 上游定位与识别信号 | 状态与采用前检查 |
|---|---|---|
| juanma0511/kknd_Root_Detector | 主题用途：将 juanma0511/kknd_Root_Detector 放在「检测器与基线诊断」中作对照或审计参考，使用 Kotlin 判断它与当前任务的边界。 上游自述（保留原文）：A tool to detect root on Android. | 未归档源项目 · ★ 69 · MIT · 2026-07-14。参考条目：用于防御性观测、概念对照或实验室审计；不是可直接照搬的安装方案。 |
| mirajabi/SecurityKit-Android | 主题用途：将 mirajabi/SecurityKit-Android 放在「检测器与基线诊断」中作对照或审计参考，使用 Kotlin 判断它与当前任务的边界。 上游自述（保留原文）：AndroShield – A comprehensive Android security toolkit for detecting root, emulator, tampering, debugging, VPN, MITM, and more. Fully configurable with modern architecture and runtime protections. | 未归档源项目 · ★ 7 · MIT · 2025-09-18。参考条目：用于防御性观测、概念对照或实验室审计；不是可直接照搬的安装方案。 |
2. 完整性修复与隐藏组合栈 · 2#
比较 specter 与 Play-IntegrityFix 等组合栈包含的 Zygisk、属性、证书/Keybox 和自动化层。文章只讲组成、依赖与失败隔离，不分发私钥或承诺 STRONG。
本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。它们用于对照、诊断或审计，不组成可批量安装的推荐清单。
| 项目 | 上游定位与识别信号 | 状态与采用前检查 |
|---|---|---|
| dpejoh/specter | 主题用途：将 dpejoh/specter 放在「完整性修复与隐藏组合栈」中作对照或审计参考，使用 TypeScript 判断它与当前任务的边界。 上游自述（保留原文）：Unified Play Integrity and root hiding stack for Android | 未归档源项目 · ★ 428 · GPL-3.0 · 2026-07-17。参考条目：用于防御性观测、概念对照或实验室审计；不是可直接照搬的安装方案。 |
| FBIVIP/Play-IntegrityFix | 主题用途：将 FBIVIP/Play-IntegrityFix 放在「完整性修复与隐藏组合栈」中作对照或审计参考，使用 仓库名、README 与发布记录 判断它与当前任务的边界。 上游自述（保留原文）：Bypass Play Integrity & SafetyNet on Android 10–16 with Keybox, Zygisk & full automation by Root Phantom Fateh. | 未归档源项目 · ★ 249 · 协议未声明 · 2026-06-03。参考条目：用于防御性观测、概念对照或实验室审计；不是可直接照搬的安装方案。 |
3. SafetyNet/Play Integrity 教程与政策脉络 · 2#
用两个指南项目解释 DenyList、旧 SafetyNet 术语与银行 App 场景，并要求用当前 Google 文档校正过时内容。教程仓库是经验来源，不是官方政策。
本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。它们用于对照、诊断或审计，不组成可批量安装的推荐清单。
| 项目 | 上游定位与识别信号 | 状态与采用前检查 |
|---|---|---|
| K3V1991/Passing-SafetyNet-with-Magisk-Zygisk-and-DenyList | 主题用途：将 K3V1991/Passing-SafetyNet-with-Magisk-Zygisk-and-DenyList 放在「SafetyNet/Play Integrity 教程与政策脉络」中作对照或审计参考，使用 android · certification · checker 判断它与当前任务的边界。 上游自述（保留原文）：Passing SafetyNet with Magisk's Zygisk and DenyList | 未归档源项目 · ★ 135 · 协议未声明 · 2024-04-12。参考条目：用于防御性观测、概念对照或实验室审计；不是可直接照搬的安装方案。 |
| SunshineYou-Enigma/-Detailed-Guide-Play-Integrity-FIX-Use-Banking-Apps-on-Rooted-Android- | 主题用途：将 SunshineYou-Enigma/-Detailed-Guide-Play-Integrity-FIX-Use-Banking-Apps-on-Rooted-Android- 放在「SafetyNet/Play Integrity 教程与政策脉络」中作对照或审计参考，使用 仓库名、README 与发布记录 判断它与当前任务的边界。 上游自述（保留原文）：未提供仓库简介 | 未归档源项目 · ★ 45 · NOASSERTION · 2025-11-23。参考条目：用于防御性观测、概念对照或实验室审计；不是可直接照搬的安装方案。 |
4. 旧式签名检测与 SuperSU 规避 · 1#
把 supersu-patcher 作为历史案例：重命名二进制可绕过简单签名扫描，但不代表通过现代硬件证明。仅讲演进关系和防守测试价值。
本组共 1 项：1 个源项目、0 个 Fork，其中 0 项已归档。它们用于对照、诊断或审计，不组成可批量安装的推荐清单。
| 项目 | 上游定位与识别信号 | 状态与采用前检查 |
|---|---|---|
| arbitraryrw/supersu-patcher | 主题用途：将 arbitraryrw/supersu-patcher 放在「旧式签名检测与 SuperSU 规避」中作对照或审计参考，使用 android · bypass · mobile · Python 判断它与当前任务的边界。 上游自述（保留原文）：Patches the popular rooting framework SuperSU to evade common root detections. This is done by renaming binaries / references to break signature based checks. | 未归档源项目 · ★ 49 · GPL-3.0 · 2021-07-24。参考条目：用于防御性观测、概念对照或实验室审计；不是可直接照搬的安装方案。 |
开始前#
只使用自有测试 App、测试账号和无支付/2FA/公司资料的备用机。记录 exact model/build/fingerprint、Android 版本、SPL、bootloader 状态、ROM 来源、Play Store/Play services 版本、App 包名/安装来源和错误发生时间。开发者还要保存 requestHash/nonce 设计、后端解密日志和 Play Console 配置，但不要记录完整 token 到公开 issue。
以下语义按 Google 官方资料于 2026-08-09 核验。Android 13+ 的 DEVICE 与 STRONG 要求和较老 Android 不完全相同，且 App 后端可按自身风险选择哪些标签、频率与响应；checker 一次绿色不能推断长期兼容。
操作步骤#
1. 先区分错误属于哪一层#
记录错误原文、网络状态、App 来源和账号状态。检查 Play Store → 设置 → 关于 → Play Protect certification；再确认 App 是官方渠道安装、Play Store/Play services/系统均已更新。若只有一个 App 失败而同设备其他官方服务正常，先考虑 App 许可、签名或服务端策略，不先归因 Root。
2. 读取 verdict，而不是只看红绿灯#
开发者用 Play Console test responses 与后端日志分别触发 app integrity、account/licensing、device recognition 和 environment 分支；普通用户只能把可信 checker 当辅助截图。将返回标签、空值、时间、build 与网络记在同一行，不把 BASIC/DEVICE/STRONG 当固定等级条。
3. 按官方顺序修复可修复项#
更新系统、Play Store 和 Play services，清除明显的网络/时间问题，从 Play 官方渠道重装 App，并按 Google 的认证排错入口处理未认证设备。若 ROM/bootloader 是原因，先获取 exact-build 厂商完整包，恢复全部被修改分区并成功启动，只有确认全为厂商签名后才考虑重锁。
4. 形成可审计结论#
复测同一请求三次，记录变化。结论应写成“App recognition 修复”“Play certification 仍失败”“解锁状态无法满足 DEVICE”“STRONG 因更新时效不满足”或“服务端策略未知”，而不是“Root 隐藏失败”。开发者应采用分级功能、可恢复对话框和人工支持，不把一个客户端布尔值变成永久封禁。
验证#
| 层 | 证据 | 验收方式 |
|---|---|---|
| App/许可 | 官方安装、包签名/版本和账号测试结果 | 修复后 app recognition/licensing 分支变化 |
| Play 环境 | certification、Play 组件版本、网络/时间 | 官方页面显示一致且可重复 |
| Device | build、SPL、lock/ROM 与返回标签 | 结论与 Google 当前语义一致 |
| 服务策略 | 后端实际响应与 remediation | 不以 checker 截图代替生产后端 |
若普通用户无法看到后端 token，只能给出“证据支持/不支持某原因”的诊断，而不是伪造确定性。恢复官方状态后仍失败，应联系服务支持并提供脱敏的构建与错误信息。
排错#
| 现象 | 常见原因 | 安全处理 |
|---|---|---|
| certification 显示未认证 | 非认证 ROM、组件/账号异常或厂商登记问题 | 按 Google 支持页更新/恢复并联系厂商 |
| verdict 为空 | 请求配置、网络、安装来源、重放或设备层 | 分层查看后端错误，不直接归因 Root |
| BASIC 有而 DEVICE 无 | 解锁、未验证或非认证镜像等低保证环境 | 目标服务需要 DEVICE 时使用锁定官方设备 |
| DEVICE 有而 STRONG 无 | SPL/关键分区更新时效或配置 | 更新官方系统；不投喂第三方证书 |
| checker 通过但 App 拒绝 | App 后端还有账户、签名、风控或本地检测 | 以目标服务支持渠道为准，不承诺绕过 |
完成清单#
- 已注明 2026-08-09 核验日期，并知道 SafetyNet Attestation 已关闭。
- 已分开记录本地检测、Play certification、app/account/device/environment 信号。
- 已保存 exact build、SPL、boot 状态、Play 组件与安装来源。
- 已按官方更新、认证与厂商恢复顺序排查。
- 未下载或分享 keybox、私钥、证书、指纹或使用真实金融账号实验。
- 结论写明证据层与未知项，没有承诺一次通过永久有效。