先明确一件事：Play Protect 的提示从哪来
Play Protect 是 Google 在 Android 设备侧提供的应用扫描与风险提示机制，它会结合本地扫描、云端信誉和安装来源等信息给出判断。提示风险可能来自真实恶意行为，也可能来自过度申请的高危权限、被标记的第三方 SDK、明文传输敏感数据，或者签名与已收录版本不一致。因此排查的关键不是急着加固或换包，而是按层次把可疑点逐一排除。
下面这套顺序的原则是：先查成本低、证据明确的项，再查需要改动代码的项。每一层都建议保留排查记录，便于后续复盘和渠道沟通。
第一层：权限——最容易被判定的显性信号
权限是 Play Protect 和设备厂商安全中心最直接的判定依据之一。一个工具类应用申请读取短信、通话记录、后台定位，即使代码里没有滥用，也容易触发风险提示。
- 导出完整权限清单，与当前版本的核心功能逐条对照，标记出「无对应功能」的权限。
- 重点检查短信、通话记录、通讯录、悬浮窗、无障碍服务、后台定位、安装未知应用这几类高危权限。
- 确认权限是否在运行时按需申请，而不是启动即申请；首次启动批量弹窗容易被判定为异常行为。
- 检查是否有第三方 SDK 在清单合并阶段静默引入权限，可对比合并后的 AndroidManifest 与主工程声明。
处理方式通常是删除无用权限、把敏感权限改为功能触发时申请，并在应用内补充用途说明。这一层改完，很多误报会直接消失。
第二层：SDK——被忽略的「连坐」来源
很多 APK 报毒并非主工程代码的问题，而是集成的某个 SDK 版本被安全引擎标记。广告、统计、推送、热更新类 SDK 尤其需要关注。
- 列出全部第三方 SDK 及版本号，优先核对近半年内有过安全公告或下架记录的组件。
- 查看 SDK 是否包含动态加载、静默下载、后台自启动等行为，这些是风险判定的高频特征。
- 确认 SDK 的初始化时机，避免在 Application 启动阶段集中初始化大量组件。
- 对可疑 SDK 做版本升级或替换，升级后重新走一遍扫描验证。
如果团队同时维护多个渠道包，建议把 SDK 清单固化成构建产物的一部分，每次发版自动比对差异，避免新引入的组件带来意外风险。
第三层：网络传输——明文与异常域名
明文 HTTP 传输敏感数据、连接已知恶意域名、使用非标准端口做后台通信，都可能被判定为风险行为。
- 抓包确认是否存在 HTTP 明文请求，尤其是登录、支付、设备信息上报等接口。
- 检查是否全局启用网络安全配置，禁止明文流量，并对自签证书做合理处理。
- 核对所有请求域名，剔除测试环境地址、临时 IP、来源不明的统计域名。
- 确认没有在后台高频请求或上传超出功能所需的设备信息。
这一层的问题往往同时影响应用商店审核和用户信任，建议与权限整改一并处理。
第四层：签名完整性——确认包没被改动
签名不一致是容易被误判也容易被忽视的一环。二次打包、证书更换、加固后重签，都可能让签名指纹与历史版本对不上。
- 用 apksigner 或 keytool 校验签名，确认 v1/v2/v3 签名方案完整且未被剥离。
- 比对当前包与线上版本的证书指纹，确认签名证书未发生非预期变更。
- 检查是否开启了完整性校验，防止包体被篡改后仍可运行。
- 若使用加固服务，确认加固流程不会破坏签名结构，并在加固后重新验证安装与启动。
签名问题通常表现为「同一应用在不同渠道表现不一致」，排查时建议以官方渠道包为基准。关于加固与完整性校验的边界，可以参考站内 服务说明 中的相关介绍。
把排查变成流程
建议把上述四层整理成发版前的检查表：权限清单比对、SDK 版本核对、网络配置检查、签名指纹校验，四项全部通过再提交渠道。遇到 Play Protect 提示时，按同样顺序回查，通常能在半天内定位到具体原因。
需要说明的是，Play Protect 的判定逻辑并未完全公开，本文给出的是基于常见触发因素的排查思路，不构成对 Google 政策的解读。若排查后仍无法定位，建议保留完整证据链，通过官方渠道反馈。更多团队协作与流程建议可查看 关于我们。