安装通过检查的是当前包，不是品牌授权
Android 会验证 APK 的结构和签名是否自洽。攻击者修改 DEX、资源或 Manifest 后，可以使用自己的证书重新签名，生成一个在技术上完整的新包。
系统能够安装这个包，不等于它拥有官方发布身份。设备侧安装校验不会替业务方判断渠道是否合法、账号是否应该登录或高风险接口是否应该放行。
重签名会破坏官方升级连续性
同一应用的覆盖升级通常要求签名身份保持连续。使用其他证书的包无法直接覆盖官方安装，往往只能改包名、卸载原应用或诱导用户单独安装。
因此检查重打包风险时，既要测试全新安装，也要测试从当前线上版本升级。只测试安装页会漏掉签名连续性、数据保留和渠道配置问题。
- 签名证书摘要是否符合发布计划
- 能否从线上版本正常升级
- 包名与版本是否符合合法集合
- 渠道修改是否发生在最终签名前
客户端信号要由服务端形成决策
客户端可以上报包名、版本、签名或平台完整性信号，但这些材料本身不是绝对可信结论。高风险操作应由服务端结合账号、版本集合、设备风险与请求行为进行判断。
策略还需要灰度、误报处理和应急回滚。如果服务端完全不区分版本与签名，客户端加固就难以阻止修改包继续调用真实业务接口。
发布记录要能唯一定位最终 APK
每个候选包至少应记录构建来源、包名、版本、签名证书摘要、文件摘要和渠道处理顺序。静态检查、安装升级与业务回归必须指向同一文件身份。
任何重新构建、重签名或渠道修改都会产生新的候选包。它需要重新进入验证流程，不能沿用上一个文件的通过结论。
- 最终文件摘要可复核
- 发布证书身份一致
- 渠道顺序固定
- 回归结果绑定同一文件
让建议落到真实应用上
提交技术栈、关键路径、目标系统范围和当前候选包，由御盾给出针对性的保护与兼容性验证建议。