为什么先定顺序，再动手改
Play Protect 的风险提示通常来自多个信号叠加：权限组合异常、后台行为可疑、网络传输不合规、安装包被重新签名等。很多团队的误区是收到提示就直接上混淆或换壳，结果既没定位到触发点，又破坏了原有签名链路。更稳妥的做法是按“证据容易获取、整改成本低、影响面大”的顺序逐项排查，先排除误报，再处理真问题。
下面这条顺序适用于自研 APK 与接入第三方分发的场景，也可以作为安全整改的内部检查表。若你的应用还涉及加固与完整性校验，可参考站内关于混淆与防二次打包的拆解（服务与加固说明）。
第一步：权限与高危 API 调用
权限是最容易被机器判定的维度，也是最快能自查的部分。重点不是“有没有申请”，而是“申请后有没有在后台持续使用”。
- 列出全部危险权限，逐个标注业务场景与触发时机，删除无对应功能入口的权限。
- 检查是否存在启动即申请、拒绝后反复弹窗、或与当前页面无关的权限请求。
- 排查后台定位、读取通讯录、读取已安装应用列表、无障碍服务等高敏感能力，确认是否有明确用户可见的用途说明。
- 核对高危 API 调用链：是否在无前台服务的情况下长时间持有唤醒锁、是否频繁读取设备标识。
这一步的产出应是一张“权限—场景—代码位置”的对照表。凡是填不出场景的权限，优先移除。权限最小化本身也是上架审核的常见卡点，相关原则在站内已有专门说明，这里不再重复。
第二步：第三方 SDK 的实际行为
很多风险提示并非来自自研代码，而是聚合在 SDK 里。排查时不要只看依赖清单，要看运行时行为。
- 导出合并后的 AndroidManifest，查看最终被注入的权限、Service、Receiver 与 Provider，确认哪些是 SDK 带进来的。
- 抓取启动后 60 秒内的网络请求，标记非业务域名的上报行为，尤其是设备指纹、剪贴板、应用列表类上报。
- 确认每个 SDK 的初始化时机，避免在用户同意隐私政策前完成初始化与数据采集。
- 对长期不更新、无正式文档、来源不明的 SDK 直接替换或移除。
如果 SDK 数量本身已经很多，行为叠加会放大可疑度，建议按“必需、可选、可自研替代”三档做收敛，而不是简单地在打包时排除。
第三步：网络传输与下载行为
明文 HTTP、自签名证书、动态下发可执行代码，都是高风险信号。排查要点：
- 全局检索 http:// 调用，确认是否已全部切换为 HTTPS，并检查是否配置了不安全的 TrustManager 或关闭了主机名校验。
- 检查是否存在从非官方渠道下载 APK、DEX、SO 并动态加载的逻辑，这类行为极易被判为可疑。
- 确认 WebView 未开启允许任意文件访问、未加载远程可控的 JS 桥接接口。
- 核对证书固定（pinning）配置是否与线上证书一致，避免因校验失败回退到不安全通道。
这一步建议用抓包工具在真机上完整走一遍主流程，记录所有外发域名与请求体字段，形成网络行为清单。
第四步：签名完整性与二次打包痕迹
如果前三步都没有明显问题，就要怀疑安装包本身被改动过。常见情况包括：渠道包被第三方工具重签、加固后签名变化、V1/V2/V3 签名方案不一致。
- 用 apksigner 校验签名方案与证书指纹，确认与开发者后台登记一致。
- 对比官方包与问题包的 DEX 数量、SO 文件、资源目录差异，查找被注入的额外组件。
- 检查是否存在重复签名块、异常 ZIP 注释、被追加的尾部数据。
- 确认分发链路上的每个环节都没有二次签名，尤其是外包渠道与聚合分发平台。
签名一旦被改动，即使代码完全干净也可能触发提示，因此这一步必须放在整改闭环的最后做验证。关于完整性校验与防二次打包的具体做法，可参见关于我们中的技术说明。
整改优先级与复验建议
建议按以下顺序落地：先删无场景权限与高危调用，再收敛 SDK 与上报行为，随后修复明文传输与动态加载，最后统一签名链路并重新出包。每次改动后保留一份行为清单，用同一套抓包与权限导出流程复验，避免“改了一处、引入两处”。
需要提醒的是，Play Protect 的判定细节并未完全公开，任何排查方法都只能提高命中率，不能保证百分之百消除提示。把上述四步做成固定的发版前检查项，比事后救火更有效。