APK 安装提示风险或报病毒的原因与排查

静态内容信号包括敏感 API、权限组合、嵌入式二进制、字符串、域名和第三方 SDK。它们可能是正常业务需要，也可能暴露真实风险。动态信号来自运行时下载、反调试、注入检测、后台行为或网络访问，需要在可控环境观察实际触发条件。

信誉信号通常围绕签名证书、包名、样本首次出现时间、下载域名和传播渠道建立。打包与保护信号则可能来自压缩结构、DEX 或 Native 变化、壳行为和非常见构建特征。最终还有产品规则差异：不同厂商的数据、命名体系和更新节奏并不相同。

复制告警全文，不要只写“报毒”。记录检测产品、标签、设备型号、Android 版本、安全组件版本、网络状态、下载来源、安装方式和时间。保存原始 APK 并计算 SHA-256，同时导出包名、versionCode 与签名证书 SHA-256。

如果告警发生在覆盖安装而不是全新安装，还应记录旧版本号与旧证书。如果告警来自应用商店审核，保留审核批次、渠道包、提交时间和商店提供的具体规则或截图。不同场景混在一起会导致错误归因。

用同一源码提交构建未加固包和候选加固包；需要比较签名时，确保除证书外的构建输入一致。先检查 APK 是否完整、签名是否符合预期、权限是否变化，再在相同设备与相同下载路径测试。

如果未加固包和加固包都告警，优先检查源码、依赖、权限与签名。如果只在加固包出现，回退到最小保护配置并按功能组逐次启用。如果只在某个下载来源出现，检查渠道信誉、重定向、内容类型和文件是否被中间环节改写。

确认存在不必要权限、来源不明 SDK、可疑网络端点或未经说明的动态代码后，应修复并重新建立基线。若行为合法但容易被误解，完善权限使用说明、隐私披露和发布资料，并评估是否能减少高风险实现。

当样本通过代码审查、签名安装和功能回归，告警仍可稳定复现且集中在特定产品时，准备定向申诉。提交文件哈希、证书、检测标签、版本、复现步骤和对照结果；不要发送密钥、用户数据或无关日志。

多引擎扫描可以提供线索，但不同引擎可能共享特征或使用不同命名，命中数量不能直接代表风险等级。沙箱没有覆盖到的行为也不能据此证明不存在。最终结论需要结合代码、依赖、运行行为和发布上下文。

检测规则随时间变化，应对每个正式版本保存证据并在实质变更后重测。不要为了短期消除标签破坏签名升级关系，也不要把加固当作隐藏真实风险的手段。