向手机厂商或安全产品提交 APK 误报申诉

保存原始告警 APK，计算 SHA-256，验证签名证书 SHA-256，并确认包名、versionName、versionCode 与发布记录一致。完成全新安装、从上一正式版升级、首次启动和关键业务流程回归。

复查敏感权限、第三方 SDK、动态代码、网络端点和告警标签对应行为。若存在真实风险或无法解释的功能，先修复并重新建立基线。申诉不是跳过安全审查的捷径。

基础身份包括应用名称、包名、版本、APK SHA-256、证书 SHA-256、文件大小、构建时间和合法下载地址。检测证据包括产品名称与版本、规则或安全组件版本、完整检测标签、截图、首次和最近复现时间。

技术说明应简洁描述应用用途、标签可能关联的合法功能、相关权限理由和第三方依赖来源。附上测试设备、Android 版本、下载与安装步骤，以及同源码未加固包或上一稳定版的对照结论。

标题写明“False positive review request”、包名、版本和标签。正文先列样本身份，再列复现环境和步骤，然后解释应用用途与关联行为，最后给出对照包、代码审查与签名安装结果。

若提交系统允许上传样本，确认其保密和数据保留条款；无法公开上传的商业包，应询问私有传输方式。所有附件使用哈希对照，避免分析人员收到多个同名但内容不同的 APK。

记录厂商、入口、工单号、提交时间、样本哈希、回复、规则更新时间和承诺的生效范围。不同产品没有统一规则库，一个厂商的处理结果不能证明其他厂商也已更新。

跟进时引用原工单，不要重复创建大量请求。若厂商要求更多信息，只提供与检测相关的最小数据，并再次核对敏感信息。内部发布负责人应知道在等待期间是否暂停、灰度或继续当前版本。

厂商通知处理完成后，优先使用原始 APK 和原始哈希复测。若重新构建后结果改变，就无法判断是规则更新还是文件变化。记录复测时间、产品版本、云端连接状态和截图。

工单关闭不代表永久保证。把结果归档到该版本发布记录，后续依赖、签名、加固配置或核心行为发生实质变化时重新建立基线。若告警再次出现，用已有工单和证据说明回归时间线。