为什么先查权限，而不是直接改代码？
Play Protect 的风险提示通常不会直接告诉你“哪一行代码有问题”，但权限列表是最外层的信号。很多被标记的 APK 并不是真的恶意，而是申请了与核心功能无关的敏感权限，比如短信、通话记录、后台定位、读取已安装应用列表。这些权限组合在 Google 的检测模型里权重很高，容易触发“可能有害”的提示。
排查时先做三件事：
- 导出 AndroidManifest.xml 中的 uses-permission 列表，和产品功能逐条对照，删掉没有明确场景的权限。
- 检查是否有第三方 SDK 在合并清单时偷偷带入权限，尤其是广告、统计、推送类库。
- 确认敏感权限是否在运行时动态申请，并且有清晰的用户告知文案。
如果权限列表干净，再进入下一步。权限问题通常整改成本最低，先排除它，能避免在后续环节浪费精力。
第二步：排查第三方 SDK 与代码行为
权限之后，重点看 SDK。很多风险提示来自集成的第三方库，而不是你自己的业务代码。常见触发点包括：
- 广告 SDK 在后台频繁拉取设备标识符，或尝试读取剪贴板。
- 统计 SDK 采集了超出隐私政策声明的信息。
- 某些 SDK 版本存在已知的恶意行为或违规收集，被 Google 列入观察名单。
可执行的检查顺序：
- 列出所有第三方依赖及其版本，优先检查广告、归因、热更新、推送类 SDK。
- 对比 SDK 官方文档和隐私政策，确认采集字段与你的隐私声明一致。
- 用静态分析工具查看是否有反射调用、动态加载 dex、执行 shell 命令等行为。
- 如果某个 SDK 无法说明用途，先移除或替换，再重新打包观察 Play Protect 是否还提示。
这一步的关键是做减法：不确定的 SDK 先拿掉，比反复解释更有效。
第三步：检查网络传输是否明文或异常
网络传输是第三个高频触发点。Play Protect 会关注 APK 是否存在明文 HTTP 请求、是否向可疑域名发送数据、是否在后台静默上传设备信息。排查时重点看：
- 是否全局允许明文流量（usesCleartextTraffic 为 true），以及是否有必要。
- 核心接口是否全部走 HTTPS，证书校验是否被绕过。
- 是否存在硬编码的 IP 地址、短链域名或与业务无关的第三方上报地址。
- 后台服务是否在用户无感知的情况下持续发送数据。
如果发现明文传输或可疑上报，先整改为 HTTPS，并移除无法说明用途的上报逻辑。网络行为整改后，建议重新提交 Play Console 或通过 Play Protect 扫描验证。
第四步：确认签名完整性与打包链路
如果前三步都没有明显问题，再查签名完整性。签名异常本身不一定直接触发风险提示，但它常和二次打包、渠道替换、加固壳冲突一起出现，间接导致 Play Protect 报毒。
检查项包括：
- APK 是否使用 v1/v2/v3 签名，签名证书是否与上次发布一致。
- 是否被第三方渠道重新签名，导致签名指纹变化。
- 加固或壳是否修改了原始 dex，造成完整性校验失败。
- 打包环境是否混入了测试证书或调试密钥。
如果签名链路复杂，建议先回归官方签名流程，用干净的构建环境重新出包。关于签名和分发的更多基础问题，可以参考站内的 服务说明，了解常见的打包与签名场景。
整改后的验证与提交建议
完成上述四步后，不要直接假设问题已解决。建议按以下顺序验证：
- 用 Play Protect 扫描新包，确认提示是否消失。
- 在 Play Console 查看是否有新的政策警告或拒绝原因。
- 保留整改前后的权限、SDK、网络请求对比记录，便于申诉时说明。
- 如果涉及企业分发或侧载场景，同步检查安装引导和用户告知是否清晰。
Play Protect 的判定是动态的，同一份代码在不同时间可能得到不同结果。因此，建立权限清单、SDK 台账、网络白名单、签名记录这四份基础文档，比每次临时排查更省事。想进一步了解应用安全与合规的基础框架，可以查看 关于我们 中的说明。