这是一份完整的 AlwaysStrong 故障排查指南：教你如何用 collect_logs 诊断报告快速定位 STRONG 掉线、Keybox 获取失败、BASIC 判级失败的原因，附逐项排查清单与日志关键章节解读，新手照着做即可。

AlwaysStrong 是一个「一次刷入即 STRONG」的 Play Integrity 模块，把 TEESimulator-RS 和 PlayIntegrityFork 合并进单个 Magisk / KernelSU / APatch 模块，自动获取 keybox 和 Pixel 指纹，理论上无需手动维护。但设备差异很大：有些机器装完就是三绿，有些却卡在 BASIC、或 keybox 一直拉不下来。本手册就是为后者准备的。

一、先拿到一份 collect_logs 诊断报告 📋

排查前，先让模块自己「体检」。AlwaysStrong 内置了日志收集器 module/collect_logs.sh，它会生成一份诊断包，供你自查或提交给社区。

三种生成方式

1. WebUI 按钮：在模块的 WebUI 里点击「Collect logs」（入口见 module/webroot/index.html），报告约 90 秒内生成；
2. Root 终端：执行sh /data/adb/modules/tricky_store/collect_logs.sh；
3. Action 参数：执行sh action.sh logs（定义在 module/action.sh）。

生成的文件是带时间戳的/sdcard/AlwaysStrong-log-20260101-120000.txt（/sdcard 不可用时回落到配置目录），文件名每份唯一，重复收集不会互相覆盖。

隐私说明：报告不包含 keybox 内容（其中持有私钥），只有 keybox 的文件名、大小、哈希和结构；也不读取序列号、IMEI、Android ID 或账户信息。唯一需要注意的是：报告包含目标应用列表（target.txt），即你装了哪些需要认证的应用，分享前可自行确认。

报告里都有什么

诊断报告按=====分节，每一节对应一类故障：

二、STRONG 掉线排查清单 🔍

先用 Play Integrity API Checker、YASNAC、Simple PIC 等工具确认当前判级，然后重按一次 Action 按钮：每次 Action 都会重建 target.txt、刷新 keybox、拉取新指纹并重启 DroidGuard，判级几秒后更新，无需重启。

1. 先查 BASIC 级阻塞项（最常见）

打开报告的Integrity blockers章节，逐项确认：

• SELinux 必须是 Enforcing。报告里如果显示selinux: PERMISSIVE，后面会跟着一行醒目提示——Permissive 状态下 Play Integrity 永远过不了，必须先修 ROM/内核，这不是模块能解决的；
• 看内核 cmdline，不看属性：模块会用 resetprop 把ro.boot.verifiedbootstate等属性刷成绿色，所以属性值永远是「好看」的。报告特意输出了androidboot.*内核启动参数，那才是未被伪装的真实锁机状态（orange 状态直接判级失败）；
• 时间是否正确：系统时间错误会导致 TLS 握手和认证有效性双双出错。报告里出现CLOCK IS BEHIND THE ROM BUILD DATE就是这种问题。

2. 再查引擎是否真的注入了 keystore2

STRONG 依赖硬件认证，而认证由 TEESimulator-RS 在keystore2进程内完成。查看报告的TEE / daemon processes章节：

• engine alive (attest_alive)应为yes；
• injected into keystore2不应是NOTHING (engine lib not mapped)——如果引擎库没映射进 keystore2，硬件认证根本没被拦截，判级最多到 DEVICE；
• 进程存活时长是隐藏线索：如果 keystore2 的启动时间比引擎进程还「年轻」，说明它错过了注入，重启一次通常即可恢复。

AlwaysStrong 由两半组成：TEESimulator-RS 负责拦截 keystore2 的 Binder 认证调用，PlayIntegrityFork 负责把 Build 属性伪装只施加在 GMS 上。理解这个分工，能帮你判断问题出在哪一半：

3. 查安全补丁一致性（DEVICE 但不 STRONG 的头号原因）

报告的Security patch coherence章节把三个来源并列：security_patch.txt、指纹文件里的SECURITY_PATCH、系统属性ro.build.version.security_patch。三者不一致，就是「安全补丁日期与认证身份不匹配」，判级会停在 DEVICE。这种情况一般按一下 Action 即可自动重新对齐。

4. 查指纹是否「落盘」

报告的Spoofed fingerprint章节会对每一份指纹 prop 文件算哈希。如果你看到哈希不同的多份文件，说明「拉到了但没写到 zygisk 真正读的那个文件」——模块读的是模块目录里的custom.pif.prop，配置目录里的只是展示副本。

另外看Google apps章节的PIF lines in recent logcat这一行：它是「伪装确实进了 GMS」的唯一直接证据（dex 在内存加载，/proc/maps看不到）。数字为 0 就手动杀一次com.google.android.gms.unstable再收集一次报告。

5. 确认选对了版本

三个发行包只有指纹伪装方式不同（详见 README.md 的 Which build to download）：

• AlwaysStrong-<ver>.zip：默认版，绝大多数设备的起点；
• -inject.zip：默认版到不了 STRONG 时换它（x86 设备上该版无法伪装 Play Integrity，别选）；
• -nopif.zip（Lite）：默认版与 GMS 冲突（Play 商店崩溃、账号页「couldn't load」）时选它，保留硬件认证 + 自动 keybox，但不再有指纹伪装。

同时只装一个，换版本 = 直接覆盖刷入新 zip。若报告出现UPDATE PENDING in modules_update，说明有待生效的更新，重启一次。

6. 冲突与干扰项

• 自定义 ROM 自带的伪装引擎（PixelProps / pihooks / entryhooks）会和模块「打架」，module/rom_spoof_block.sh 会在每次启动时把它们禁用；除非你有特殊需求，否则不要创建no_rom_spoof_block标志文件去关闭这个保护；
• 装了 LSPosed / Xposed 的框架进程不要进认证目标列表——通过被 hook 的进程做认证会直接破坏 STRONG，模块本身已做了 Xposed 感知处理；
• 查看报告末尾的模块列表章节，确认没有 TrickyStore、其他 PIF fork、SafetyNet Fix 等残留模块（安装器本会自动清理，若你后来手动装回了它们，就是冲突源）。

三、Keybox 失效排查清单 🔑

STRONG 的最终依赖是一个未被吊销的硬件 keybox——模块能自动拉取、自动换新，但无法替你「造」一个。Keybox 相关的所有逻辑集中在 module/keybox_fetch.sh：每次下载都会本地哈希比对，只在内容有更新时才原子替换，拉取失败则保留旧文件。

1. 读懂 Network 章节（大多数 Keybox 故障都在这里）

报告的 Network 章节是现场实测，不是猜测：

• ping 1.1.1.1 / 8.8.8.8：绕过 DNS 的裸 IP 连通性；
• dns <keybox 主机>: ok / FAIL：部分 AOSP ROM 的 DNS 解析器起得晚，这是它们首次开机拿不到 keybox的典型原因——稍后重按 Action 通常就正常了；
• 四个下载器实测：asfetch（模块自带 Rust 下载器）、busybox-wget、curl、wget逐一实测下载 keybox 端点，附带耗时。哪一行ok就说明你这台机器上哪个下载器可用——模块本来就会按 asfetch → busybox → curl → wget 的顺序自动回退；
• last-good engine (cached)：记录上次成功的下载器（缓存于.kb_engine），下次优先尝试，避免每次空烧超时。

四个下载器全部 FAIL时，基本可以断定是网络/代理/DNS 层面问题，先换网络环境验证。

2. 读懂 Keybox 元数据章节

报告出于隐私只输出元数据，但信息量足够：

新装的设备特别注意：全新安装会预置一个上游演示 keybox 让引擎有东西可加载，此时 Action 的提示很关键——离线状态会显示no internet — keybox not fetched（而不是误报 ok），在线时才会真正走keybox updated / keybox ok / keybox fetch failed三种结果。

3. 状态指示与自定义 keybox

• 模块 description 前的🟢🟢🟢状态球来自镜像的/status接口（由 module/status_fetch.sh 拉取并写回 module.prop），WebUI 状态区还会显示当前 keybox 名称（如evokerrkey27），方便确认镜像端是否在用同一个 key；
• 每小时后台服务会自动复查 keybox，只有发现更新的才会换入，所以「keybox 失效」往往先表现为镜像端轮换后本地迟迟未跟上——重按一次 Action 即可强制刷新；
• 想用自己的 keybox：WebUI 打开Custom keybox并选文件，模块会停止自动拉取（custom_keybox标志文件存在时 keybox_fetch.sh 直接退出）；想把自动刷新指向别的镜像，则给 keybox 拉取脚本设置KEYBOX_BASE_URL，脚本会先验证 payload 再替换现有文件。

四、提交求助时的报告要点 💬

以上清单走完仍有问题，把/sdcard/AlwaysStrong-log-<时间戳>.txt附到社区支持请求里即可。为了让报告一次说清，注意这几点：

1. 先复现再收集：在判级掉线「当下」收集报告，而不是重启前；
2. 若 PIF 行数为 0，先杀掉com.google.android.gms.unstable再收集；
3. 报告中的时间戳文件名可用于连续两次对比（例如「Action 前一份 + Action 后一份」），能明显看出是哪一步发生了变化。

模块的自启动 Action、每小时刷新、看门狗信息都保存在磁盘日志（autopif.log、.action_boot.log、module.log）中，报告已自动带上尾部若干行；如需更深入的引擎/构建细节（TrickyStoreOSS、JingMatrix TEESimulator 等可选引擎），可参考 docs/ADVANCED.md。

总结

• 一切排查从collect_logs 诊断报告开始，三种生成方式任选；
• STRONG 掉线：先查 Integrity blockers（SELinux / orange / 时钟），再查 keystore2 注入与安全补丁一致性，最后核对版本选择与模块冲突；
• Keybox 失效：重点看 Network 章节的 DNS 与四下载器实测，再用 Keybox 元数据章节确认文件完整性；
• 记住底线：模块能自动维护一切，但 STRONG 的最终前提是一个未被吊销的硬件 keybox——这一点连模块本身也无法代替镜像端。