原始包与候选包
明确原始版本、保护策略版本、候选包、签名与渠道对应关系，避免用不一致的对象测试或发布。
发布门禁的最小事实集
身份
范围
平台、设备与业务路径
每次验证应写清目标系统、ABI、分发方式、关键路径和外部依赖，而不是笼统写“兼容”。
结果
通过项、例外与待复核项
将通过标准、异常归因、未覆盖范围和复测计划明确记录，避免把局部结果过度外推。
处置
灰度与回滚对象
上线判断需要对应可用的灰度、监控、例外处理和回滚版本，安全策略不应脱离交付节奏。
为什么兼容性不是一个单一指标
冷启动、包体、内存、系统版本、设备差异、Native 依赖、渠道包和关键业务路径描述的是不同维度。一个有效的兼容性结论必须带有测量对象、方法、时间和适用范围；没有这些信息时，只能视为待验证事项。
同样，保护策略的调整不应绕过已有回归和发布流程。将候选包和验证结果写入可追溯记录，能让研发、安全、测试和发布人员在出现问题时更快定位范围。
相关资料
查看 App 加固发布门禁范围常见问题
加固产物可安装，是否就能发布？
不能。还应根据目标平台、安装升级、关键业务路径、外部依赖、兼容范围、异常和回滚对象完成项目验证。
性能数据应该如何公开？
应披露测量对象、版本、方法、指标、覆盖范围和限制。不同构建类型或不同候选版本之间不能直接推导加固前后性能结论。