先明确一件事：Play Protect 提示不等于已确认恶意
Play Protect 的风险提示通常来自静态特征、行为启发式与云端信誉的综合判断，它给的是一个“需要人工复核”的信号，而不是最终定性。因此收到提示后，第一反应不该是立刻加壳或换渠道，而是按固定顺序做证据收集。排查顺序的核心原则是：先排除误报成本最低的项，再处理改动成本最高的项。下面这条路径适合大多数工具类、内容类与电商类 App。
第一步：核对权限声明与运行时行为是否一致
权限是最常见的触发点，也是最容易自查的部分。重点不是“有没有敏感权限”，而是“声明与使用是否对得上”。
- 打开合并后的 AndroidManifest，确认是否存在业务上完全用不到的权限，尤其是短信、通话记录、通讯录、位置后台、悬浮窗、无障碍服务等。
- 检查 targetSdk 与权限申请时机：启动即申请一堆权限、或在无明确场景下反复弹窗，容易被行为模型标记。
- 确认无障碍服务、设备管理器、通知监听等特殊权限是否真有对应功能，若为历史遗留应直接移除。
- 核对隐私政策与实际采集项是否一致，不一致本身就是高风险信号。
这一步的产出应是一份“权限—功能—代码位置”的对照表，删掉无法解释的条目后再复测。
第二步：逐个排查第三方 SDK
大量 APK 报毒案例的根因在依赖里，而不是自研代码。广告聚合、统计、推送、热更新、加固壳、模拟器检测类 SDK 都可能引入敏感调用。
- 导出依赖清单，列出所有含 native 库或动态加载能力的 SDK。
- 对照各 SDK 官方文档，确认其声明的权限与采集字段，与第一步的对照表交叉验证。
- 重点关注会读取已安装应用列表、剪贴板、IMEI/OAID、后台自启动的模块，这些是启发式规则的高频命中项。
- 对版本过旧、已停止维护或来源不明的 SDK 直接升级或替换，不要只做混淆掩盖。
如果团队同时维护多个渠道包，建议把 SDK 清单纳入发布检查项，避免某次集成把风险重新带回来。涉及分发与上架服务的流程，可参考 我们的服务说明 中对包体检查环节的描述。
第三步：检查网络传输行为
明文 HTTP、证书校验被关闭、动态下发可执行代码，这三类问题既影响合规也容易被判为可疑行为。
- 抓包确认是否存在 http:// 请求，尤其是配置下发、日志上报、图片加载等“非核心”链路。
- 确认没有全局关闭证书校验（TrustManager 全信任、HostnameVerifier 恒真）的实现。
- 检查是否存在从网络下载 dex/jar 后动态加载的逻辑，热更新方案应改为合规实现或移除。
- 确认域名与证书有效期正常，异常跳转和失效证书同样会拉低信誉评分。
传输层问题通常改动小、收益直接，建议在 SDK 排查同期完成。
第四步：验证签名完整性与包体一致性
签名问题常被忽略，但它直接影响“这个包是不是官方发布”的判断。请确认：
- 发布包使用正式签名证书，而非 debug 或测试证书；
- 签名方案与目标版本匹配，v1/v2/v3 配置正确，未被二次签名覆盖；
- 包名、版本号、证书指纹与后台登记信息一致；
- 渠道包在加固、重签名后校验值可复现，避免分发环节被替换。
若包体在分发过程中被第三方修改，即使原始代码干净也会触发提示。关于签名与安装异常的更多处理思路，可参见 关于我们 中的技术说明。
复测与整改记录怎么写
完成上述四步后，重新构建、重新提交，并保留一份整改记录：问题项、证据（截图或日志）、修改内容、复测结果。这份记录在向渠道申诉、向客户解释时非常有用。若提示仍未消失，再考虑加固或人工申诉，而不是一开始就上重手段。
总结一句：权限看一致性，SDK 看来源与版本，网络看明文与动态加载，签名看证书与包体完整性。按这个顺序走，多数 Play Protect 风险提示都能在半天内定位到具体原因。