先固定候选包与复现条件
同名文件可能来自不同构建、签名或保护配置。排查前应记录包名、版本、签名证书摘要、文件摘要、保护配置、设备、系统版本与安装方式。
同时准备与候选包对应的未加固基线，并使用相同账号、网络、数据状态和启动入口复现。条件不一致时，很多差异无法归因给加固过程。
- 文件与签名身份固定
- 设备和系统版本固定
- 安装升级路径一致
- 账号网络和数据状态一致
找到最早出现差异的启动阶段
把启动拆成进程创建、Application 初始化、ContentProvider、类加载、Native 库加载、首屏资源和业务入口。记录候选包在哪个阶段首次偏离基线。
最早差异比最后一条错误提示更有价值。后续异常可能只是连锁反应，直接围绕末尾堆栈修改配置容易掩盖真正原因。
按载体检查常见兼容点
Java 与 Kotlin 侧重点观察反射、动态类加载、序列化、注解和被名称规则依赖的入口。Native 侧检查 ABI、依赖解析、JNI 注册、符号可见性和初始化顺序。
资源与第三方 SDK 还可能依赖 Manifest、文件路径、完整性校验、WebView、热修复或自身的反篡改逻辑。每次只改变一个变量，才能判断修复是否真实有效。
- 反射与动态加载入口
- JNI 注册与依赖库
- Manifest 和资源路径
- 第三方 SDK 自校验
修复后必须回到发布范围复验
某台设备不再闪退只说明当前复现点被消除。还需要在同一候选身份上重新执行安装升级、启动、关键业务、目标系统范围和异常回滚。
无法获得的设备或系统版本应明确标记未覆盖，并限制发布范围。不能用另一个版本的成功结果替代缺失的兼容证据。
让建议落到真实应用上
提交技术栈、关键路径、目标系统范围和当前候选包，由御盾给出针对性的保护与兼容性验证建议。