先分清提示来自哪里
Play Protect 的风险提示可能出现在安装时、扫描本地 APK 时，也可能出现在应用运行后的定期扫描中。不同触发点对应的排查方向不一样：安装时被拦，更可能是包体特征或签名问题；运行后被提示，更可能是权限、后台行为或网络请求触发了启发式判断。先记录提示原文、出现时机、设备型号与系统版本，再开始动手。
需要说明的是，Play Protect 的具体判定规则并未完全公开，下面给的是工程上可验证、可复现的排查顺序，不代表官方判定逻辑。
第一步：权限与敏感能力
权限是最容易被误判也最容易自查的一项。按以下顺序过一遍：
- 列出 manifest 中所有危险权限，逐个确认是否真的被业务代码调用；
- 检查是否存在声明了但从未使用的权限，尤其是短信、通话记录、无障碍、悬浮窗、后台定位这类高敏感项；
- 确认权限申请时机是否与功能场景匹配，避免启动即申请一堆权限；
- 检查是否有动态申请的权限在低版本系统上被静默授予。
常见问题是接入第三方库时被自动合并进 manifest 的权限，开发者自己并不知情。可以用合并后的 manifest 报告来核对，而不是只看源码里的声明。
第二步：第三方 SDK 与依赖
很多“APK 报毒”最终追到某个 SDK 版本上。排查时建议：
- 导出完整依赖树，标出所有含原生库、含广告或统计能力的 SDK；
- 核对每个 SDK 的版本号与官方最新版本，优先升级到修复过安全问题的版本；
- 检查 SDK 是否在后台自启动、频繁唤醒或读取设备标识；
- 确认 SDK 初始化是否被放在用户同意隐私政策之前。
如果某个 SDK 已停止维护，考虑替换或移除。整改时保留依赖变更记录，便于后续对比。
第三步：网络传输行为
网络层的问题通常表现为明文请求、异常域名或不符合预期的上报频率。检查项包括：
- 是否仍存在 HTTP 明文请求，尤其是配置下发、日志上报接口；
- 是否配置了网络安全策略，明确允许与禁止的域名；
- 是否存在向未知域名或 IP 直连发送设备信息的代码；
- 请求频率是否异常，例如启动阶段密集上报。
抓包是最直接的手段：在测试机上完整走一遍主流程，看有没有预期之外的请求。发现可疑上报，先定位到具体 SDK 或代码位置，再决定关闭还是替换。
第四步：签名完整性与包体一致性
如果前三步都没有明显问题，就要怀疑包体本身是否被改动。重点核对：
- 发布包的签名证书是否与预期一致，是否存在调试签名或历史证书混用；
- 是否启用了 v2/v3 签名方案，签名块是否完整；
- 包内是否存在二次打包留下的多余文件或重复 entry；
- 构建产物与源码提交记录是否能对应上。
签名不一致不仅会触发安全提示，也会影响后续更新覆盖安装。团队应固定签名流程，把证书管理和构建校验纳入发布检查单。关于完整性校验与防二次打包的分工，可以参考站内 服务说明 中的相关章节。
建议的排查顺序与记录方式
综合来看，推荐顺序是：权限 → SDK → 网络传输 → 签名完整性。理由是前两项改动成本低、定位快，后两项需要构建与证书配合。每一步都记录：检查项、结论、证据（manifest 片段、依赖版本、抓包截图、签名指纹）、处理动作。这样即使提示再次出现，也能快速比对差异。
如果排查后确认是误报，可以通过正规渠道提交申诉，同时保留完整的排查记录。团队内部的发布规范也值得同步更新，把上述四项做成上线前的固定检查项。更多关于应用安全与发布流程的说明，可查看 关于我们。