先明确一件事：提示不等于病毒
Play Protect 的判定来自本地扫描与云端信誉的结合，触发原因可能是高危权限组合、可疑的第三方 SDK 行为、明文或异常的网络传输，也可能是签名与包体完整性对不上。它的提示更像一个“需要人工复核的信号”，而不是最终结论。所以排查的目标不是立刻加固，而是先找出到底哪一类特征被命中。
下面这条顺序按“改动成本从低到高、误判概率从高到低”排列，建议逐项走完再决定整改动作。
第一步：权限清单与运行时申请逻辑
先导出合并后的 AndroidManifest，重点看三类：
- 高危权限是否真的需要。短信读取、通话记录、后台定位、悬浮窗、无障碍服务，这些是高频触发项。很多项目是某个 SDK 自动合并进来的，业务侧根本没用。
- 权限声明与申请时机是否一致。声明了却从不申请，或者一启动就批量申请，都会被行为模型标记。
- 是否存在已废弃权限或重复声明。合并冲突产生的重复节点会让包体看起来“不干净”。
处理方式很直接：用 tools:node="remove" 移除不需要的合并权限，把敏感权限改为按场景申请。这一步通常能解决相当一部分提示。
第二步：第三方 SDK 的采集范围与联网行为
权限没问题，接下来看 SDK。重点不是“用了几个 SDK”，而是它们各自在做什么：
- 列出所有会自启动、注册后台服务或定时任务的 SDK。
- 检查是否在用户同意隐私政策前就发起网络请求或读取设备标识。
- 确认 SDK 版本是否为官方仍在维护的版本，老版本常带有已被标记的采集逻辑。
- 对可疑 SDK 做隔离测试：逐个关闭后重新打包，观察提示是否消失。
这一步的常见误区是只删掉“看起来最可疑”的那一个。建议用二分法，一次只动一个变量，否则无法归因。关于 SDK 采集范围与自启动风险的更细分析，可以参考站内相关文章的思路，但排查动作仍要以本次包体的实际行为为准。
第三步：网络传输是否明文或校验缺失
网络层的问题往往被忽略，但它是信誉判定的重要输入：
- 是否还有
http://明文请求，尤其是下发配置、上报日志这类“非核心但高频”的接口。 - 是否配置了
usesCleartextTraffic=true却没有任何限制。 - 证书校验是否被全局关闭，或存在信任所有证书的 TrustManager。
- 下载的可执行文件、dex、so 是否做了来源与完整性校验。
整改建议是统一走 HTTPS，对关键接口做证书绑定，动态下发的内容必须校验签名或哈希后再使用。这类改动对业务影响小，但对降低可疑度很有效。
第四步：签名完整性与包体是否被改动
如果前三步都干净，就要怀疑包体本身。检查项包括：
- 签名证书是否与线上历史版本一致，是否被替换为调试证书或第三方证书。
- 是否存在 v1/v2/v3 签名方案混用导致的校验异常。
- dex、so、资源文件是否在打包后被二次修改，例如渠道包工具、加固平台、内测分发渠道的再处理。
- 包内是否残留测试代码、调试开关、硬编码的密钥或后台地址。
签名与资源层面的校验方法，站内已有专门文章展开，这里只强调一点：任何在签名之后对包体的修改，都可能让完整性校验失败，进而被判定为可疑。渠道分发、加固、重签这几个环节要明确责任边界，避免同一份包被反复处理。若需要了解加固与完整性校验的分工，可查看 我们的服务说明。
可执行的排查顺序总结
把上面的内容压缩成一张动作清单：
- 导出合并 Manifest，清理无用与高危权限；
- 列出 SDK 清单，逐个隔离验证，优先处理自启动与提前采集；
- 扫描明文请求与证书校验逻辑，统一收敛到 HTTPS；
- 核对签名证书与包体哈希，确认分发链路没有引入额外改动；
- 每次只改一个变量，重新提交并观察提示是否复现。
最后提醒运营侧：Play Protect 的提示可能随云端模型更新而变化，同一个包在不同时间的结果未必一致。因此整改后要保留对照记录，包括包体哈希、签名指纹、SDK 版本和测试机型，方便后续复盘。若团队需要把上述流程固化成发布前的检查项，可以参考 关于我们 中提到的工程实践思路，把权限、SDK、网络与签名四项做成上线前的固定卡点，比事后救火更省成本。