为什么会出现“渠道报毒、本机不报”
同一个 APK，上传到应用市场被判为风险或疑似病毒，装到手机上用本地杀毒扫一遍却干干净净。这不是谁在误判，而是两边用的不是同一套东西。理解差异，才能判断要不要加固、加固后怎么验证。
常见差异集中在三处：
- 规则来源不同。渠道侧通常有自建规则、第三方引擎和人工复核叠加，本地杀毒依赖手机上的病毒库版本，两者更新节奏不一致。
- 检测对象不同。渠道扫描的是上传的安装包本身，包括签名、证书链、清单文件、打包结构；本地引擎更多看安装后的运行行为，对静态特征关注度较低。
- 判定阈值不同。渠道为了控制风险，往往采取更保守的策略，命中一条可疑规则就可能拦下；本地引擎要兼顾误报成本，阈值相对宽松。
所以“本机不报”只能说明当前病毒库和当前设备环境下没有命中，不能反证安装包没有问题，也不能证明渠道一定误判。
先分清是“规则问题”还是“包问题”
在讨论加固之前，建议先做一次归因。可以按下面的顺序排查：
- 拿到渠道给出的具体提示文案、命中的规则名称或风险等级，能申诉的先走申诉通道问清楚。
- 核对上传的包与线上分发的包是否一致，包括版本号、签名指纹、渠道包差异。多渠道打包时，某个渠道包被单独标记很常见。
- 检查清单文件里的权限、组件导出状态、动态加载与反射调用、以及集成的第三方 SDK 版本。
- 用多个本地引擎交叉扫描同一份样本，而不是只信一台手机上的一个结果。
如果归因结果是“包内确实存在可疑代码模式或敏感权限组合”，那属于包本身的问题，加固只能缓解特征，不能替代整改。如果归因结果是“规则保守、特征误命中”，加固的价值就体现在改变静态特征上，但同样需要回归验证来证明没有引入新问题。
加固能解决什么，不能解决什么
加固的核心作用是改变代码与资源的静态形态，让基于特征匹配的扫描难以直接命中，同时提高逆向和二次打包的成本。它不能消除权限申请、不能隐藏网络请求行为、也不能让一个本身违规的功能变得合规。
因此判断“还要不要加固”，可以看两个条件：一是渠道拦截主要来自静态特征而非行为判定；二是团队有能力承担加固后的兼容性与稳定性回归成本。两个条件都满足，加固才值得做。
回归验证：加固前后怎么对比
加固不是打完包就结束，关键是建立一套可重复的验证流程。建议至少覆盖以下环节：
- 样本对齐。加固前后的包使用同一份代码基线、同一套签名配置，避免把其他改动的影响算到加固头上。
- 多渠道复扫。把加固后的包重新提交到此前报毒的市场，同时用多个本地引擎复扫，记录每一处的结论变化。
- 功能回归。重点验证加固后容易出问题的部分：反射与动态加载、JNI 调用、热修复、推送与第三方登录、以及涉及签名校验的逻辑。
- 安装与升级路径。覆盖全新安装、覆盖安装、跨版本升级三种场景，确认签名一致性和升级不被拦截。相关排查思路可参考站内关于签名与安装问题的整理。
- 线上灰度。先小流量发布，观察崩溃率、启动耗时和渠道审核反馈，再全量。
验证结果要留档：同一份样本在哪些引擎、哪些版本下分别得到什么结论。后续病毒库更新或渠道规则调整时，这份记录就是判断“新报毒是不是加固失效”的基线。
给运营和开发的协作建议
渠道报毒往往先到运营手里，再转给开发。建议约定固定信息模板：报毒渠道、提示原文、样本哈希、签名指纹、复现环境。信息齐全，开发才能快速判断是规则问题还是包问题。发布流程上，把“加固后多渠道复扫”作为上架前的固定卡点，比事后申诉更省时间。更多上架与分发相关的服务说明可以查看 服务页面，历史排查案例整理在 博客列表。
最后回到问题本身：本机不报不代表安全，渠道报毒也不必然要加固。先归因，再决定；决定加固，就用回归验证说话。渠道报毒、病毒库差异、APK 安全这三件事，只有放在同一套验证流程里，结论才站得住。