先理解提示的性质，再动手排查
Play Protect 的提示来源通常分两类：一类是静态扫描发现代码或配置特征可疑，另一类是设备端行为观察发现联网、权限调用异常。两者对应的排查路径不同，所以第一步不是改代码，而是记录提示原文、出现机型、系统版本与安装来源，并确认同一 APK 在干净设备上能否复现。信息记录完整后再进入下面四层排查，顺序不要打乱，否则容易在无关项上浪费时间。
第一层：权限声明与运行时申请是否匹配
权限是最容易被判可疑的第一入口。重点看三件事：
- 清单里声明的权限是否都有真实业务场景支撑，尤其是短信、通话记录、通讯录、位置后台、无障碍服务等高敏感项。
- 是否存在声明了却从未在代码中使用的权限，这类冗余声明在扫描中往往是减分项。
- 运行时申请是否与用户操作同步触发，避免启动即弹窗、连续弹窗、拒绝后反复弹窗。
整改动作很直接：删除无用权限，把敏感权限改为按需申请，并在申请前给出清晰说明。若应用确实需要高敏感能力，应在隐私政策与商店说明中写清用途。
第二层：第三方 SDK 的采集范围与后台行为
多数 APK 报毒的实际诱因在依赖库而非自研代码。排查时逐个列出 SDK 及其版本，重点关注：
- 是否在未同意隐私政策前就初始化并联网。
- 是否申请了自启动、关联启动、后台常驻等能力。
- 是否采集设备标识、安装列表、剪贴板等与业务无关的信息。
- 是否存在已知旧版本漏洞或已被下架的组件。
处理方式是升级到官方最新版本、关闭非必要采集开关、把初始化时机推迟到用户同意之后。对于来源不明或长期不维护的 SDK，建议直接移除。关于 SDK 数量与行为风险的关系，可参考站内服务说明 /index.php#services 中的检测项划分。
第三层：网络传输是否规范
网络层的问题常被忽略，但它同时影响安全判定与用户信任。检查点包括：
- 是否全部走 HTTPS，是否存在明文 HTTP 回退或自定义的不安全协议。
- 是否关闭了证书校验，或使用了全局信任所有证书的配置。
- 是否存在向未知域名、短链接、动态 IP 上报数据的行为。
- 下载可执行文件、热更新包的行为是否有校验与来源说明。
建议在发布包中固定域名白名单，开启证书绑定，移除调试期的抓包信任配置。动态下发代码或插件的能力应谨慎使用，并在隐私政策中如实披露。
第四层：签名完整性与包体一致性
如果前三层都没有明显问题，就要怀疑包体本身被改动。核对项：签名证书指纹是否与发布记录一致、是否启用了 v2/v3 签名、安装包哈希是否与构建产物匹配、资源文件与清单是否被二次注入。渠道包、加固后重签、外包代打包都是高风险环节。建议建立构建产物哈希台账，并在发版前做一次签名与完整性自检。相关思路可延伸阅读 /about.php 中的流程说明。
可执行的排查顺序小结
- 记录提示信息与复现环境。
- 核对权限声明与申请时机，清理冗余权限。
- 盘点 SDK 版本、初始化时机与采集范围。
- 检查 HTTPS、证书校验与域名白名单。
- 校验签名指纹、签名方案与包体哈希。
- 整改后重新构建、重新提交观察，保留前后对比记录。
按这个顺序推进，多数 Play Protect 提示都能定位到具体原因。需要强调的是，排查的目标不是绕过检测，而是让权限、数据采集与传输行为真正合规，这样才能同时解决 APK报毒 与后续上架审核中的连带问题，把安全整改做成一次可复用的流程。