先别慌：Play Protect 提示不等于“病毒”
Google Play Protect 是安卓设备上的安全扫描服务，它会在安装时或定期扫描已安装应用。当它弹出风险提示，可能的原因很多：应用申请了敏感权限、集成了被标记的第三方 SDK、网络传输不符合安全规范，或者 APK 签名与预期不一致。对开发者和运营来说，关键不是立刻重新打包，而是按可执行的顺序定位问题。以下排查顺序从最容易验证、最常出问题的环节开始。
第一步：检查权限声明与运行时请求
权限是 Play Protect 最先关注的点。很多风险提示源于“声明了但没用到”或“过度申请”的权限。
- 打开 AndroidManifest.xml，列出所有
uses-permission，逐条问：这个权限在当前版本真的需要吗？ - 重点看 短信、通话记录、通讯录、位置、存储、无障碍服务 这几类。如果只是历史遗留，直接移除。
- 检查运行时请求逻辑：是否在用户无操作时静默申请？是否在后台反复请求？这类行为容易被判定为可疑。
- 如果权限确实必要，确保在隐私政策中说明用途，并在应用内提供清晰的授权理由。
权限整改后，先在小范围设备上安装验证，观察 Play Protect 是否还提示。如果提示消失，问题就出在权限层。
第二步：排查第三方 SDK 与依赖库
第三方 SDK 是另一个高频触发点。有些广告、统计或推送 SDK 因为行为不合规被 Google 标记，集成后会导致整个应用被提示风险。
- 用
./gradlew app:dependencies或 Android Studio 的依赖分析，列出所有第三方库及版本。 - 对照 Google 的 开发者政策 和 Play Protect 相关公告，确认是否有已知被标记的 SDK。
- 检查 SDK 是否在后台收集 IMEI、MAC 地址、已安装应用列表等敏感信息。这类行为在较新安卓版本上会被限制或标记。
- 如果发现可疑 SDK，优先升级到官方最新版；若无法升级，考虑替换或移除。
注意：不要只依赖混淆来掩盖 SDK 行为，混淆不能改变实际调用逻辑。如果对加固和混淆的边界不清楚，可以参考我们关于 APK 加固与完整性校验 的说明。
第三步：检查网络传输安全
明文 HTTP 传输、不安全的 TLS 配置、证书校验被绕过，都可能触发 Play Protect 的风险提示。
- 确认所有网络请求使用 HTTPS，并且没有在
network_security_config.xml中全局允许明文流量。 - 检查是否禁用了证书校验（如自定义
TrustManager信任所有证书）。这种做法在安全扫描中会被视为高风险。 - 如果使用了 WebView，确认加载的页面是 HTTPS，且没有开启
setAllowUniversalAccessFromFileURLs等危险选项。 - 检查是否有硬编码的 IP 地址或非标准端口，这类连接可能被判定为可疑通信。
网络层整改后，用抓包工具确认实际流量，避免代码改了但配置没生效。
第四步：验证签名完整性与包体一致性
如果前三步都没问题，就要怀疑包体是否被篡改或签名不一致。Play Protect 会校验 APK 签名，签名异常会直接触发警告。
- 用
apksigner verify --verbose your.apk检查签名方案（v1/v2/v3）是否完整，签名是否有效。 - 对比官方发布渠道的签名指纹与当前包是否一致。如果使用了第三方加固或重打包，签名可能已被替换。
- 检查 APK 内是否有多余的 dex 文件、so 库或资源，这些可能是被注入的代码。
- 如果使用了加固服务，确认加固后的包没有破坏原始签名，并且通过了 Google Play 的签名校验。
签名问题往往意味着包体在分发过程中被改动，需要从构建流水线开始排查，而不是只改代码。关于签名和完整性校验的更多细节，可以查看 关于我们 中的技术说明。
排查顺序总结与整改建议
建议按 权限 → SDK → 网络传输 → 签名完整性 的顺序推进，因为前两步改动成本低、验证快，后两步涉及构建和分发链路，耗时更长。每次只改一个维度，改完立即在真机上安装验证，避免多个变量混在一起导致无法定位。
如果四步都排查完仍未解决，可以收集 Play Protect 的提示截图、设备型号、安卓版本和 APK 签名信息，通过 Google Play 开发者支持渠道申诉。同时，保留每次整改的记录，便于后续审计和用户沟通。