设备是 OnePlus 7 Pro（GM1910），氢 OS 11.0.5.1，Magisk 30.7。问题很具体：Claude 应用登录被 Play 保护机制拦住了，提示设备未通过认证。root 机器装个应用还要被 Google 的认证卡脖子，这事得解决。
结论先给：修好了，Claude 应用恢复正常登录。方法是把手机的 Play Integrity 环境修到 MEETS_BASIC_INTEGRITY 稳定通过，对绝大多数应用（包括 Claude）这就够了。
MEETS_DEVICE_INTEGRITY 在 Android 11 上过不去，2026 年没有公开解法。这不是配置问题，是 Google 关上了门，后文有实测依据。结果验证#
修复后，Claude 应用正常登录：
用 SPIC 看 Play Integrity 的原始判定（2026 年 11 月 5 日实拍）：Device recognition verdict 是橙色的一格 MEETS_BASIC_INTEGRITY，DEVICE 和 STRONG 空心。也就是说，Google 服务端给这台设备的判定是 BASIC，而 Claude 应用认这个判定。
整个排查也是在这台手机上由 Claude 驱动完成的——adb 推文件、跑模块脚本、uiautomator 读界面、SPIC 触发检测，人只需要在关键节点点一下授权。
排查过程：三套栈，八种配置#
| # | 模块栈 | 指纹 / 配置 | 结果 |
|---|---|---|---|
| 1 | IntegrityBox v46 | 自带 Legacy 流程（Canary 指纹 + 自动 keybox） | BASIC，且模块本身有缺陷（见下） |
| 2 | osm0sis PlayIntegrityFork v19 | Pixel 10a Canary | BASIC |
| 3 | osm0sis PIFork + Tricky Store OSS | OnePlus 7 Pro 国行原厂指纹 | BASIC |
| 4 | 同上，杀掉 TrickyStore 守护进程 | 同上 | BASIC |
| 5 | osm0sis PIFork | REDMAGIC 11 Pro 认证指纹 | BASIC |
| 6 | osm0sis PIFork + spoofProvider + AOSP 软件 keybox | Pixel XL（sailfish，first_api=25，按 README 的 DEVICE 标准配方） | BASIC |
| 7 | Zygisk Next + KOWX712 PIF v4.9-inject-s + Specter + Tricky Store OSS（2026 年 1 月社区指南全套） | Pixel 10 Pro XL 自动指纹 + Specter 有效 keybox | BASIC |
| 8 | 同上，补丁级别对齐指纹（all=2026-10-05） | 同上 | BASIC |
六种指纹，三种确认过 PIF 真实注入了 DroidGuard 进程（不是白配），结果一致。结论：在 Android 11 上，任何公开指纹都过不了 DEVICE。
过程里有三个坑，单独拎出来讲。
坑一：IntegrityBox 根本没在干活#
论坛教程的第一步是装 IntegrityBox。我装了 v46，跟着流程走完，Play 商店纹丝不动。
问题出在注入层面。IntegrityBox 的 zygisk 库只把 Play 商店进程（com.android.vending）注入了，对 com.google.android.gms 和 gms.unstable（DroidGuard 所在进程）一个字节都没注入。而 Play Integrity 的判定恰恰发生在 GMS 里。
验证方法很简单，两条命令：
# 看 PIF 的 zygisk 库加载进了哪些进程
su -c 'grep -i playintegrityfix /proc/<pid>/maps'
# 看 PIF 日志里出现过的进程
adb logcat -d | grep 'PIF/Native'
我用 osm0sis 的 PlayIntegrityFork 替换后（模块 ID 同为 playintegrityfix，直接覆盖安装），GMS 和 unstable 的 maps 里立刻出现了模块的 so 文件。同一个设备、同一个系统，换个模块注入就正常了。所以 IntegrityBox 在这台机器上是坏的，它 WebUI 做得再漂亮也没用。
坑二：预览指纹这条路线整个死了#
论坛教程写于 2025 年 8 月，当时"开启 Use Preview fingerprint"确实能过。2026 年的现在，osm0sis 在 README 里写得很直白：
Pixel Beta/Canary fingerprints have changed and can no longer pass DEVICE integrity, so can now only be used for STRONG integrity setups.
KOWX712 的 PIF README 也确认了同样的事：pixel_beta 指纹连 legacy 检查都拿不到 DEVICE。Canary 指纹本来就是六周寿命的消耗品，现在连短暂的命也没了。
坑三：keybox 路线在 Android 11 上是空头支票#
2026 年的主流方案靠 TrickyStore / Specter 给的有效 keybox 走硬件认证路径。我把 Specter 的 keybox 装上了，它还认真做了 Google 吊销校验（日志里写着 “Keybox is not revoked”），证书我也拉下来对过 Google 官方的 attestation status 列表，四张证书都不在吊销名单里。
白搭。翻 TrickyStore 的拦截日志，认证事务只有一条，来自 uid 10205——查了下是手机 QQ 的 FEKitHardwareKey。GMS（uid 10120）在整个认证过程中没有发起过任何 keystore 请求。Android 11 的 DroidGuard 根本不走 keybox 这条路，keybox 配得再正确也无的放矢。
这条路是给 Android 13+ 的 deviceRecognitionVerdict 准备的。老系统吃不到。
一堆小坑，按浪费时间的顺序#
- SPIC 的判定说明弹窗。点判定旁边那个问号，出来一个带五个翻页圆点的轮播，第四页恰好是 MEETS_STRONG_INTEGRITY 的绿色解释页。我一度以为认证过了，高兴早了。真正的判定看主界面 “Device recognition verdict” 那行。
- SPIC 里的红色 UNRECOGNIZED_VERSION。那是 App Integrity（应用完整性），含义是"这个 app 是侧载的，Play 不认识它"。侧载的检测器 app 当然不被认识，跟设备认证无关，别被吓到。
- adb input tap 会整体失效。USB 线重插之后，
input tap注入的点击全部被吞，触摸屏本身正常（手指能操作）。重启手机恢复。症状诡异，排查时如果发现"怎么点什么都没反应"，先重启再怀疑人生。 - 李跳跳的悬浮窗。它常驻窗口排在窗口列表第一位，会吃掉部分区域的注入点击。排查期间我 force-stop 了它好几次。
- 系统设置崩溃残留的幽灵窗口。氢 OS 的设置在"开发者选项 → OEM 解锁"页会因 OemLockManager 空指针崩溃（这台机器的 oemlock HAL 服务缺失，
service check oemlock是 not found），崩完留下一个看不见但持有焦点的 “Application Error” 窗口，把所有触摸都吃掉。重启解决。 - Specter 的 security_patch.sh 写的是设备真实补丁，不是指纹声称的补丁。走 keybox 路径需要两者一致，得手动
echo "all=<指纹补丁>" > /data/adb/tricky_store/security_patch.txt。虽然在这台 A11 上这步改了也没用，但换到新系统上这是必踩的坑。
最终保留的方案#
新栈本身是干净的，模块组合留下来了，BASIC 稳定——Claude 应用的登录就是靠它恢复的：
- Zygisk Next 1.5.2（Magisk 内置 Zygisk 关闭，Enforce DenyList 关闭）
- PlayIntegrityFix v4.9-inject-s（KOWX712，就是社区说的 PIF [INJECT]）
- Specter 1.5.0（keybox 目录管理 + 吊销校验 + 定时任务，WebUI 的每个开关都有对应的
features/*.sh脚本，可以纯命令行驱动） - Tricky Store OSS v3.1.0
- HMA-OSS（需要隐藏 root 管理器时再用）
配置文件就两个：/data/adb/modules/playintegrityfix/pif.prop（指纹和开关），/data/adb/tricky_store/（keybox 和补丁级别）。改完 am force-stop com.google.android.gms; am force-stop com.android.vending 再测（force-stop 一次只收一个包名），不用重启。
验证别只看 Play 商店，SPIC 直接给三级判定的原始结果，Play 商店的"认证"显示还有服务端缓存延迟。
DEVICE 还有没有路#
有，但都不轻松：
- 私有指纹。osm0sis 的配方写得很清楚：<A13 的 DEVICE 需要 first_api_level 在 21 到 25 之间（对应出厂安卓 5.0 到 7.1 的老机型）、从未公开泄露的指纹。我试过的 sailfish（Pixel XL）符合条件但公开了七八年，早被拉黑。这类指纹现在只在 XDA 私下小范围流通，拿到后写进 pif.prop 一分钟就能验证。
- 升 Android 13+。新系统走 A13+ 的判定路径，keybox 路线才是主战场。但 OnePlus 7 Pro 的官方 ROM 止步于 Android 12，刷第三方 A13 是另一个大工程了。
- 接受 BASIC。Claude 的登录证明了大多数应用走到这一步就够了。受影响的只剩 Play 商店那行小字和少数强校验应用。
我的选择是第三条，等哪天遇到真正卡 BASIC 之上的应用再说。
给后来人的检查顺序#
如果你也在老设备上被应用登录卡住，按这个顺序排查能少走弯路：
- 先确认注入真的发生了：
logcat | grep PIF或查进程 maps，别信模块的 WebUI 显示 - 装 SPIC 看原始判定，BASIC 过了说明 root 隐藏没问题；应用还被拦，先看应用要的是不是 DEVICE
- 查指纹的 first_api_level：大于等于 26 的指纹在老系统上走不了 keybox 路线，等于白配
- 确认 keybox 在 Google 吊销名单之外
- 以上全对还不过，那就是指纹本身被封了，换私有指纹，别再调配置了
Google 在 2025 到 2026 之间收紧了老系统的判定逻辑，这篇里所有"过不去"的结论都基于 2026 年 11 月的实测。以后策略再变，以 osm0sis 仓库的 README 为准，它更新得比任何教程都勤。