把加固结果变成可发布的候选包

用同一候选包完成基线、兼容、异常归因和回滚验证。

核心结论

App 加固验收必须绑定同一候选包、明确设备与系统范围，并覆盖安装升级、启动、关键业务路径、崩溃、性能、灰度和回滚。单次安装成功、静态扫描或构建通过都不能单独代表正式发布完成。

提交应用技术栈、关键路径与兼容范围，获取针对性的保护建议。

先把真正影响发布的问题拆开

安全强度必须和运行稳定性一起考虑。先定位容易被利用的路径，再判断保护方式、兼容成本与验收条件。

常见痛点

需要同时判断

验收的价值在于让发布决策可重复，而不是把一次成功演示整理成一份漂亮报告。

答案只覆盖公开方法与适用条件。具体项目结论以真实候选包和约定的验证范围为准。

安装并启动成功是否代表验收通过？

不代表。还需要关键业务路径、升级、异常、兼容性、性能和回滚验证。

加固后闪退应先查什么？

先确认候选包身份和可复现条件，再按启动阶段、类加载、Native 装载、资源和第三方 SDK 分层归因。

性能应该看平均值吗？

平均值不足以描述尾部风险。应记录测试条件，并结合分位值、崩溃、包体、内存和真实关键路径。

缺少某个系统版本怎么办？

明确标记未覆盖，并在灰度和发布范围中限制。不能用其他版本的结果代替。

以下官方资料用于核对平台机制和安全边界，是正文的参考依据，不替代本文的技术分析。