为什么 Play Protect 会提示风险？
Google Play Protect 是 Android 系统内置的安全服务，它会扫描设备上的应用，并根据行为、权限、代码特征等判断是否存在潜在风险。当你的应用被提示风险时，通常意味着某些行为触发了它的启发式规则或已知恶意软件特征。与其盲目加固或重新打包，不如按照以下顺序逐一排查，找到根因。
第一步：检查权限申请是否合理
权限是 Play Protect 最关注的信号之一。过度申请或与功能无关的敏感权限（如短信、通话记录、位置、通讯录）极易触发警告。请对照以下清单：
- 是否申请了与核心功能无关的权限？例如一个手电筒应用请求读取通讯录。
- 是否在运行时动态申请了敏感权限，但用户拒绝后仍反复弹窗？
- 是否使用了被废弃或限制的权限，如 Android 11 后的后台位置、Android 13 的通知权限等？
- 是否在 manifest 中声明了未使用的权限？第三方 SDK 可能自动合并了权限。
整改建议：移除所有非必要权限，对必须的权限提供清晰的用途说明，并确保在用户拒绝后应用仍能降级运行。如果对权限合规性不确定，可以参考我们的应用安全评估服务进行深度检测。
第二步：审查第三方 SDK 的行为
许多风险提示并非来自你的代码，而是集成的第三方 SDK。广告、统计、推送等 SDK 可能包含被 Play Protect 标记的代码片段，或存在动态加载、反射调用等敏感行为。排查方法：
- 列出所有集成的 SDK 及其版本，检查是否有已知的安全公告。
- 使用静态分析工具（如 MobSF）扫描 APK，查看 SDK 是否包含下载可执行文件、访问敏感 API等行为。
- 检查 SDK 是否在后台频繁收集设备信息（IMEI、MAC 地址等），这在 Android 10 后属于违规。
- 尝试逐个移除可疑 SDK，重新打包测试，观察 Play Protect 是否仍报警。
如果发现某个 SDK 版本过旧，优先升级到最新版。部分 SDK 提供合规配置选项，可关闭不必要的采集。
第三步：检查网络传输是否安全
明文 HTTP 传输、不安全的 TLS 配置或与可疑域名通信，都可能被 Play Protect 视为风险。请确认：
- 所有网络请求是否使用 HTTPS，且证书有效？
- 是否在代码中硬编码了 IP 地址或非标准端口？
- 是否使用了自签名证书或忽略了证书校验（如 TrustAll）？
- 是否与已知的恶意域名有通信？可通过威胁情报平台比对。
整改建议：强制使用 HTTPS，移除不安全的 TrustManager，对敏感数据加密传输。如果应用需要与自有服务器通信，确保域名已备案且无异常跳转。
第四步：验证签名完整性
签名是应用的身份凭证。如果 APK 被二次打包或签名不一致，Play Protect 会直接提示风险。排查要点：
- 对比官方渠道与当前安装包的签名证书指纹（SHA-256）是否一致。
- 检查 APK 是否被重新签名，尤其是通过非官方渠道分发时。
- 确认签名方案是否启用 V2/V3，仅 V1 签名易被篡改。
- 使用
apksigner verify命令验证签名完整性。
如果发现签名被篡改，说明包可能被恶意修改，需要立即从官方渠道重新下载。关于签名校验的更多细节，可参考我们的技术博客。
总结与整改顺序
当 Play Protect 提示风险时，建议按以下顺序排查：权限 → SDK → 网络传输 → 签名完整性。每一步都记录检测结果，逐步缩小范围。多数情况下，问题出在权限过度申请或第三方 SDK 的隐蔽行为上。如果自行排查困难，可以借助自动化扫描工具，或联系专业安全团队进行深度分析。记住，及时整改不仅能消除警告，也能提升应用的整体安全性。