App 加固后闪退，如何按层定位原因

先冻结候选包和复现条件

排查最常见的失真来自测试对象变化。研发重新构建、测试重新签名、渠道修改资源或加固配置被覆盖后，文件名仍可能相同。此时日志、堆栈和修复动作指向的不是同一个产物，任何因果判断都不可靠。

至少记录包名、版本、文件 SHA-256、签名证书摘要、构建来源、保护配置版本、渠道状态、设备型号、系统版本、ABI、安装方式、账号数据和网络条件。同时准备由同一源版本生成的未加固基线。

复现步骤应从应用处于什么状态开始写：全新安装、覆盖升级、进程被杀、冷启动、深链、推送、后台恢复或特定账号。只写点击图标后闪退，无法区分启动、数据迁移和业务入口问题。

• 基线与候选来自同一源版本
• 文件和签名身份可复核
• 设备、安装和账号条件固定
• 复现步骤能够由另一人重复

incident: protected-candidate-startup
candidate:
  artifact_sha256: REDACTED
  signing_sha256: REDACTED
  protection_config: config-v3
environment:
  os: target-version
  abi: arm64-v8a
  install: upgrade-from-production
reproduction:
  entry: launcher
  account_state: signed-in
first_difference:
  phase: native-library-load
  protected: failed
  baseline: passed
next_variable: native-group-auth
rollback_candidate: config-v2

按时间线寻找最早差异，不追最后一条报错

Android 冷启动包含进程创建、Application 初始化、主线程、Activity 创建、布局和首次绘制。在真实应用中，ContentProvider、启动框架、热修复、动态类加载、Native 库和第三方 SDK 还会插入这条时间线。一个早期失败可能导致后续类缺失、资源未初始化或空指针。

把基线和保护候选的时间线并排记录：进程是否创建，Application 是否进入，Provider 是否完成，类加载器是否准备，关键 SO 是否装载，JNI 是否注册，首帧是否出现，业务入口是否返回。最早一个不一致的节点就是下一轮证据采集的中心。

如果崩溃发生在监控 SDK 初始化前，线上平台可能没有事件。需要结合系统日志、平台崩溃报告、Native tombstone 或受控诊断构建，但公开内容不得泄露真实包名、符号、地址和设备标识。

Java、Native、资源和第三方 SDK 要分层排查

Java 与 Kotlin 层重点检查反射、注解、序列化、动态类加载、泛型签名、组件类名和由字符串引用的入口。名称混淆、控制流或代码迁移可能破坏这些隐式契约。应根据真实依赖补最小保留规则，而不是把整个包排除后宣布问题解决。

Native 层检查目标 ABI、所有依赖、NDK API 下限、JNI 注册、异常、线程和符号。Android NDK 文档说明部分符号在装载时解析，目标系统不存在的 API 可能让库在业务分支执行前就失败。

资源与 Manifest 可能影响主题、启动图、Provider、FileProvider、WebView、动态特性和渠道 SDK。第三方登录、支付、推送、地图、音视频、热修复和风控 SDK 还可能具有自校验或隐式初始化顺序，需要使用真实业务账号和环境验证。

用单变量实验缩小保护故障半径

找到最早差异后，把候选保护范围按功能或依赖分组。每次只回退或调整一个组，并保持源代码、依赖、签名、渠道、设备和业务输入不变。新的构建必须获得新的文件摘要和配置版本。

如果调整后现象消失，还需要复现一次原配置并重新出现，或者通过更直接的证据证明因果。例如某个 JNI 注册组恢复后注册成功且关键调用通过，比单次不崩溃更有说服力。这个过程是观察、重检、判断和边界四步，而不是试到能打开为止。

二分范围适合快速缩小区域，但最终仍要找到具体契约：名称、签名、线程、装载、资源或性能。只把整个业务模块永久排除，可能把高价值代码留在未保护状态，也没有形成可维护的规则。

闪退、ANR 和性能退化不能混成一个问题

进程异常退出、主线程长时间无响应和启动变慢的证据不同。Android 官方建议从 ANR cluster signature 和线程状态开始，并提醒 nativePollOnce 等帧可能只是采样时主线程空闲，不一定是根因。看到 Native 名称不代表问题一定来自 SO。

启动性能应同时观察 TTID 与 TTFD。保护后首帧正常但数据初始化明显推迟，用户仍会感到不可用。反过来，首帧稍慢但关键业务稳定，也需要由项目预算决定是否接受，不能用统一数字替所有应用做判断。

线上崩溃和 ANR 数据要与版本、文件身份、设备和渠道关联。平台聚类可能合并相似堆栈，但工程团队仍要确认该事件是否来自保护候选、是否在基线存在、是否只集中于特定系统或 ABI。

• 区分 crash、ANR、卡顿和业务错误
• 同时记录 TTID 与 TTFD
• 崩溃符号与候选包版本匹配
• 按系统、ABI 和渠道观察聚类
• 不把采样栈顶自动当作根因

修复完成后回到发布范围，而不是停在复现设备

某台设备不再闪退，只说明当前复现点消失。修复候选必须重新执行全新安装、从线上版本升级、冷启动、后台恢复、深链或推送入口、关键业务、目标系统、目标 ABI 和第三方 SDK 路径。

还要确认保护范围没有被无意缩空。静态检查可以核对目标代码是否仍进入预期保护层，运行检查确认稳定性和输出一致。修复如果通过永久排除整个核心模块实现，应重新评估风险和替代控制。

最终报告分为已验证、失败、未执行和不适用。缺少设备或环境时限制灰度并列出下一步，不用另一个版本的成功记录代替。发布还要具备监控、停止条件和已经演练的回滚包。

先建立能比较的诊断证据包

排查加固后闪退需要同时保存未保护基线和保护候选，但两者必须来自同一源码、依赖锁定、资源、签名路径和构建环境。证据包至少包含文件 SHA-256、签名摘要、版本、保护配置标识、设备型号、系统与补丁、ABI、安装方式、账号状态、复现入口和准确时间。缺少这些主键时，日志来自哪个包、符号对应哪次构建、设备是否残留旧数据都无法确认，后续分析再细也可能建立在错误对象上。

运行记录应覆盖崩溃前的时间线，而不是只截最后一屏。Java 异常保存完整 cause chain 和相关线程，Native 崩溃保存 signal、fault address、ABI、模块加载与匹配符号，启动问题记录进程创建、Application、ContentProvider、首个 Activity 与关键 SDK 初始化。日志还要与用户操作、深链、推送或后台恢复入口对齐，才能判断最早差异发生在装载、初始化还是业务调用。

证据包需要脱敏和最小化。真实账号、访问令牌、用户输入、内部服务器地址、完整业务符号和未公开保护配置不应进入公开报告；内部记录按权限保存原件，外部协作使用稳定事件标识和必要片段。这样既能让研发复现，也不会为了展示技术深度泄露新的攻击材料或客户信息。

采集工具本身也可能改变时序。打开严格 JNI 检查、详细 tracing、调试器或高频日志后，竞争条件和启动耗时可能与用户环境不同。诊断应先用低侵入记录确认故障，再逐步增加观测；如果只在调试模式消失或出现，要把这种差异作为证据，而不是直接把带调试器的结果当作生产复现。每次采集都记录工具、开关和持续时间。

复现数据也要固定。远程配置、时间窗口、服务端灰度、账号权限和本地数据库迁移都可能决定某条代码是否执行；只复制安装包而不保存这些状态，第二天可能无法再次触发。证据包应记录可公开的配置版本和测试数据准备步骤，必要时使用专用测试环境冻结依赖，避免把外部变化误判为加固配置修复。

• 基线与保护包来自同一构建输入
• 文件、签名、配置和符号一一对应
• 设备、系统、ABI 和安装方式完整
• 日志覆盖崩溃前时间线
• 用户操作与日志时间能够对齐
• 公开证据完成凭据和业务脱敏

把闪退回归固定进 CI 与灰度发布

一次人工修复不能防止下一次编译器、SDK 或保护配置升级重新引入问题。应把曾经失败的最小复现入口加入回归集，并在加固产物生成后重新安装最终候选，执行冷启动、后台恢复、深链、核心业务、异常输入和目标 ABI。流水线保存候选身份、步骤结果和崩溃附件，任何用不同文件补测的结果都不能合并到原候选结论。

设备矩阵需要按风险分层，而不是无限罗列型号。高优先层覆盖主要用户系统、最低支持版本、主要 ABI、关键厂商和真实分发路径；扩展层覆盖新系统预览、低占比设备和已知特殊 SDK。若高优先层存在未覆盖项，发布决策必须写明限制、灰度比例、监控指标和停止条件，不能用低风险模拟器的通过记录代替。

灰度期间应把崩溃率、ANR、启动失败和关键业务错误按应用版本、保护配置、系统、ABI 和渠道切分，并保留未保护或上一稳定版本作为比较基线。出现稳定差异时优先停止扩量和回滚，再复用同一证据包定位；监控只能告诉团队哪里异常，不能自动证明保护是根因，所以仍需单变量候选重检。

回归脚本要校验业务结果，不只是检查进程存活。登录状态、订单状态、加解密输出、文件落盘、后台任务和服务端响应都需要可判断的断言；异常输入要确认错误类型和恢复动作没有变化。只用 UI 自动化点击到最后一页，可能错过中间逻辑返回默认值、重复请求或静默降级。对关键路径保留服务端或本地可脱敏核对的结果证据。

发布后的首轮监控要能回到同一配置版本。若服务端远程开关可以调整保护相关路径，变更也要进入台账并标记时间，否则监控曲线变化无法与候选包区分。紧急关闭某一组保护只能作为恢复手段，随后仍需生成新候选并完整回归，不能把线上长期依赖远程绕开的状态当作最终修复。

事故复盘应把技术根因转成可执行门禁。遗漏反射规则就增加产物扫描和入口测试，符号不匹配就让归档校验阻断发布，设备覆盖不足就调整风险矩阵。只记录某次配置参数改成什么，下一次代码和工具链变化后仍会复发；门禁必须描述要验证的行为和证据，而不是绑定一个偶然有效的值。

门禁还应验证失败路径真的会阻断。故意放入摘要不匹配的候选、缺失符号归档或未覆盖的高优先设备，确认流水线无法进入发布；只测试全部材料齐全的成功路径，不能证明团队在赶版本时不会绕过检查。任何人工豁免都要有范围、批准人、到期时间和补测计划，并在下一次发布前自动提醒。

• 历史失败入口进入永久回归集
• CI 安装并测试最终加固文件
• 设备矩阵按业务风险分层
• 灰度指标可按候选身份切分
• 停止和回滚条件提前配置
• 人工豁免具有批准人和到期时间
• 失败路径也要验证门禁会真实阻断