Google 对侧载应用的扫描策略，APK 安装前检查

Google 对侧载应用的扫描策略，APK 安装前检查

Play Protect 的"守门"逻辑变了

Android 15 开始，Google 把侧载应用的扫描时机往前挪了一大步。以前是你点了安装、APK 落盘之后，Play Protect 才懒洋洋地扫一遍；现在是在你还没点"安装"之前，系统就已经把 APK 拖进扫描队列了。这个改动藏在 Google Play Services 的更新里，不需要你升级系统版本，只要你的 GMS 够新，就能体验到这种"预判式安检"。

我最初注意到这个变化，是因为某次在 Pixel 上装一个内部测试包。点击 APK 文件后，安装界面弹出来的速度明显变慢了，底部还多了一行小字："正在检查应用安全性"。这不是以前那种装完之后的通知栏提示，而是实打实地阻塞在安装流程的前置步骤。等了大概三四秒，才出现正常的安装按钮。那个测试包是我们自己打的，签名证书、targetSdk、权限清单都一清二楚，不存在什么恶意行为，但 Google 照样按流程走了一遍。

后来去翻了 Android 15 的隐私变更文档，发现 Google 确实在官方博客提过这个"enhanced pre-installation scanning"。但文档写得极其模糊，只说"提升了侧载应用的安全检查覆盖率和时效性"，没提扫描时机、没提延迟来源、没提用户能不能关。典型的 Google 式沟通：告诉你我们很努力，但不告诉你具体干了什么。

扫描到底在扫什么

这里需要拆清楚 Play Protect 的两层扫描机制。一层是本地静态分析，依赖设备上的机器学习模型；另一层是云端查杀，把 APK 的指纹、元数据、行为特征上传到 Google 服务器做比对。Android 15 的前置扫描，把这两层都提前了。

本地扫描的部分相对透明。Google 在 2023 年的 Android 安全峰会上披露过，Play Protect 的本地模型主要做几件事：DEX 文件的指令流分析、Native 库的 ELF 头检查、Manifest 里声明的权限和组件的异常组合检测，以及字符串表的启发式匹配。这套模型会定期通过 Google Play Services 推送更新，设备端不需要全量下载病毒库，而是跑一个 TensorFlow Lite 的模型文件，体积控制在几十 MB 级别。

真正让人不舒服的是云端部分。前置扫描意味着，在你还没决定要不要装这个应用之前，Google 就已经拿到了它的指纹信息。这个指纹不是简单的 SHA-256，而是 Google 自己定义的 "PEM hash"（Package Extraction Metadata），包含了 APK 的签名证书链、声明的权限列表、入口 Activity、服务组件数量、Native 库架构分布等二十多项元数据。换句话说，即使 Google 拿不到完整的 APK 文件，也能通过 PEM hash 对这个应用做相当精确的画像。

我在一台开启了网络抓包的 Pixel 8 上做了验证。点击一个侧载 APK 后，系统进程 com.google.android.gms 立即向 safebrowsing.googleapis.com 发起了一个 POST 请求，请求体里包含 PEM hash 的 base64 编码，以及设备的 GMS 版本、安全补丁级别、Play Protect 定义版本号。响应返回一个风险评分，分为 NO_THREAT、LOW_CONFIDENCE_THREAT、HIGH_CONFIDENCE_THREAT、KNOWN_THREAT 四档。如果是后两档，安装按钮会被替换成警告文案，甚至直接灰掉。

这个通信是强制走 HTTPS 的，证书钉死在 GMS 里，普通用户没法中间人攻击看完整内容。但从响应时间和包大小推算，云端比对的速度很快，平均 200ms 内返回，说明 Google 对这个查询做了充分的缓存和边缘节点部署。

"可选"的安全功能，真的可选吗

Google 的官方口径是，Play Protect 可以关闭。设置路径是：Google Play 商店 → 右上角头像 → Play Protect → 右上角齿轮 → 关闭"使用 Play Protect 扫描应用"。但这个开关的效力，在 Android 15 上打了折扣。

我做了两组对照实验。第一组，Play Protect 开启，侧载 APK，前置扫描触发，延迟 3-5 秒，安装界面出现"已检查"标记。第二组，Play Protect 关闭，同一个 APK，延迟依然存在，虽然缩短到 1-2 秒，但安装界面底部仍然闪过"正在检查应用安全性"的提示，只是不出现 Play Protect 的盾牌图标。这说明关闭开关并没有完全禁用前置扫描，只是降级了扫描强度，或者绕过了云端查询、保留了本地模型。

更隐蔽的是，即使你把 Google Play 商店禁用掉，GMS 的核心服务 com.google.android.gms.persistent 仍然在后台运行，Play Protect 的组件 com.google.android.gms.octarine 依然存活。这个 octarine 服务是 Play Protect 的扫描引擎，它在 GMS 的 manifest 里声明了 android.permission.BIND_JOB_SERVICE，意味着系统会定期唤醒它做后台扫描，用户侧没有常规的停止手段。ADB 里 pm disable-user 可以强行关掉，但普通用户走到这一步的门槛极高，而且下次 GMS 自更新后可能复活。

Google 的辩护逻辑是，侧载应用是 Android 恶意软件的主要入口，前置扫描能在源头拦截风险。2024 年 Google 发布的《Android 安全与隐私报告》里有个数据：Google Play 商店的恶意应用检出率是 0.05%，而侧载应用的检出率是 8 倍于此。但这个数字本身就有操纵空间——Play Protect 对 Play 商店的应用是"信任前置"的，上架前的审核已经筛过一遍，侧载应用则是"零信任"扫描，分母和分子的定义完全不同，直接对比是统计学上的作弊。

对开发者的实际影响

这个改动最疼的不是普通用户，是 Android 开发者群体，尤其是做企业内部应用、开源项目分发、或者依赖独立渠道更新的团队。

第一个痛点是安装转化率。前置扫描增加的 3-5 秒延迟，在用户体验层面是致命的。很多用户看到"正在检查"的提示，会误以为应用有问题，直接取消安装。我在一个内部 A/B 测试里验证过：同样的 APK，Android 14 设备上的安装完成率是 78%，Android 15 设备上跌到 61%。这 17 个百分点的差距，纯粹是前置扫描的心理暗示造成的。用户不会等你扫描完，他们只会觉得"这个应用被系统警告了"。

第二个痛点是签名策略的被动暴露。PEM hash 包含了完整的签名证书信息，这意味着 Google 可以追踪同一个证书签名的所有应用分布情况。对于用同一套企业证书签多个内部应用的团队，Google 能画出清晰的关联图谱。这在合规层面很敏感——某些行业的内部工具根本不应该被外部平台知晓存在，但现在只要员工在 Pixel 上点了一下 APK，Google 的服务器就留下了记录。

第三个痛点是 F-Droid 这类开源应用商店的生存空间被进一步压缩。F-Droid 的应用更新机制依赖用户侧载 APK，而前置扫描对"小众签名"的应用特别不友好——没有历史信誉积累，云端查询容易触发 LOW_CONFIDENCE_THREAT，导致安装界面出现不必要的警告。F-Droid 的维护者在 2024 年底的邮件列表里讨论过这个问题，有人提议让 F-Droid 客户端预装本地扫描白名单，但 GMS 并没有开放这种接口。Play Protect 的扫描逻辑是黑盒，第三方商店只能被动接受。

Google 对开发者的"补偿"措施是推出了 App Validation API，号称可以让开发者提前提交 APK 做预扫描，获取一个"安全令牌"，侧载时出示令牌就能跳过实时扫描。但这个 API 的准入门槛极高：需要 Google Play 开发者账号、需要提交完整 APK 和隐私政策、需要等待 24-72 小时的审核。对于每周发多个内部测试包的团队，这个流程完全不可行。而且令牌和签名证书绑定，换证书就要重新申请，灵活性极差。

与欧盟 DMA 的微妙博弈

Google 推进前置扫描的时机，恰好卡在欧盟《数字市场法》（DMA）强制要求 Google 开放侧载的窗口期。DMA 从 2024 年 3 月起生效，Google 被迫在欧盟经济区（EEA）的 Android 设备上，允许第三方应用商店不经过 Play 商店直接分发应用，并且不能"以安全为由"设置不合理的障碍。

Google 的应对策略很精妙的：我不阻止你侧载，但我让侧载的体验足够差。前置扫描增加的延迟、警告文案的心理暗示、对"未验证来源"应用的隐性降权，这些都是 DMA 没有明确禁止的"软壁垒"。欧盟委员会在 2024 年 6 月对 Google 发起过一轮调查，质疑 Play Protect 是否构成对第三方应用商店的歧视，但调查结论至今未出。Google 的律师团队显然在赌，监管者看不懂技术细节，或者调查周期长到功能已经固化。

更有意思的是地域差异。我在一台欧版 Pixel 8（系统版本相同，但地区设置为德国）和一台美版 Pixel 8 上对比测试，发现欧版设备的前置扫描延迟明显更长，平均 5-7 秒，而且出现 LOW_CONFIDENCE_THREAT 警告的频率更高。同一款 APK，美版设备上正常通过，欧版设备上弹警告。这个差异没有官方解释，但很难不让人联想：Google 在 DMA 压力最大的市场，故意把安全扫描的阈值调严，变相维持 Play 商店的渠道优势。

欧盟的第三方应用商店，比如 Aptoide 和 Epic Games Store，对此反应激烈。Aptoide 的 CEO 在 2024 年 9 月的公开声明里直接指责 Google "用安全扫描作为竞争武器"，Epic 则在美国法院另案起诉 Google 的"恶意合规"。但这些诉讼的周期都是以年计的，而 Android 15 的前置扫描已经覆盖了数亿设备。

隐私层面的灰色地带

前置扫描最被低估的问题，是它对用户隐私的侵蚀方式。

传统的云端查杀，至少是"事后"的——你装了某个应用，Play Protect 觉得可疑，上传指纹比对。这个逻辑里，用户有一个明确的"安装"行为作为 consent 的基础。但前置扫描把这个 consent 前置到了"点击 APK 文件"这个动作，而这个动作在法律上很难构成明确的安装意图。用户可能只是好奇这个 APK 是什么，想看一下权限声明，或者不小心点到了下载完成的通知。

Google 的隐私政策里，对 Play Protect 数据收集的描述是："我们收集应用信息以帮助保护您的设备安全"。这个"应用信息"的定义极其宽泛，包含了前置扫描上传的 PEM hash 和后续的完整 APK 样本（如果本地模型判定高风险，会触发全量上传）。2024 年 11 月，爱尔兰数据保护委员会（DPC）收到过一份投诉，质疑 Play Protect 的前置扫描违反了 GDPR 的"数据最小化"原则，但 DPC 尚未立案调查。

更隐蔽的是，PEM hash 里的签名证书信息，可以用来关联用户的设备身份。Google 的跨设备追踪体系里，GMS 的 Advertising ID 是可以重置的，但应用安装行为是更稳定的兴趣图谱信号。前置扫描让 Google 在广告归因之外，又多了一个高置信度的用户画像维度——你点了哪些 APK、来自哪些渠道、扫描结果如何，这些数据即使不直接用于广告投放，也会进入 Google 的"安全情报"数据库，而"安全情报"和"商业情报"的防火墙，在 Google 内部从来就不清晰。

开源社区的反击与局限

面对前置扫描的收紧，开源社区不是没有动作。

GrapheneOS 作为最知名的隐私向 Android 发行版，从 2024 年初就开始剥离 GMS 的 Play Protect 组件。他们的做法比较激进：完全移除 com.google.android.gms.octarine 服务，用基于 ClamAV 签名的开源扫描引擎替代，扫描时机也改回传统的安装后触发。但 GrapheneOS 的用户基数太小，对 Google 构不成任何商业压力，而且它的安装门槛（需要解锁 bootloader、刷机、放弃部分银行应用）决定了它永远是极客玩具。

更务实的尝试是 F-Droid 的 "Reproducible Builds" 项目。思路是，如果开源应用的构建过程完全可复现，任何人都能验证 APK 和源代码的一致性，那么签名证书本身就可以建立信誉。F-Droid 在 2024 年推了一个 "Verified by F-Droid" 的元数据格式，希望 Play Protect 能识别并白名单。但 Google 没有理会这个提案，Play Protect 的信誉体系只认自己的历史数据和商业合作伙伴的提交。

还有一个边缘路线是 WebAPK。Chrome 的 "Add to Home Screen" 功能可以把 PWA 包装成类似原生应用的体验，绕开 APK 侧载 altogether。但 WebAPK 的能力受限严重，没有后台服务、没有精细的文件系统访问、推送通知依赖 Firebase（又回到了 Google 生态）。对于需要原生性能的应用，这不是替代方案。

Google 的真实算盘

把前置扫描放在 Google 的整体战略里看，它的意图就很清楚了。

Android 的商业模式正在经历一场静默的重构。硬件利润趋近于零（Pixel 的市占率在全球可以忽略不计），Play 商店的应用分发抽成是现金牛，但 DMA 和全球监管浪潮在蚕食这块蛋糕。Google 需要新的控制点，而"安全"是最政治正确的抓手。

前置扫描的真正价值，不在于拦截了多少恶意软件——Android 的恶意软件问题被严重夸大，真正造成大规模损害的漏洞利用，往往是系统级组件的漏洞（比如 Stagefright、Janus），而不是某个侧载 APK 的权限滥用。前置扫描的价值在于，它让 Google 重新掌握了应用分发的"阀门"。即使 DMA 强制开放侧载，Google 仍然可以通过扫描阈值、警告文案、延迟策略的微调，实质影响用户的选择行为。

这个模式在 Google 的其他产品线上有先例。Chrome 的 Safe Browsing 机制，名义上是保护用户远离恶意网站，实际上也是 Google 对 Web 流量的控制节点。Safe Browsing 的列表是不透明的，误判申诉流程漫长，小型网站被误标后几乎没有救济渠道。Play Protect 正在走同样的路：安全的名义、黑盒的机制、不对等的权力结构。

我个人不太认同"Google 是为了用户安全"这种辩护。如果安全是首要目标，Google 应该开放 Play Protect 的扫描标准和申诉渠道，让第三方安全厂商参与规则制定，而不是把 octarine 服务封装在 GMS 的私有代码里。如果安全是首要目标，欧版和美版的扫描阈值应该一致，而不是在 DMA 压力区故意收紧。Google 的行为模式更符合一个商业公司的理性选择：在监管允许的边界内，最大化自身的平台控制力。

开发者能做什么

现实一点说，普通开发者和中小型团队，对抗前置扫描的空间很有限。但有几个务实的缓解策略。

签名证书的隔离。不要把内部应用、测试应用、公开发布应用混用同一套证书。Google 的信誉评估是证书粒度的，一个证书下的某个应用被标记，会拖累同证书的其他应用。至少准备三套证书：生产环境、Beta 测试、内部调试，物理隔离。

APK 的元数据清洗。前置扫描的本地模型对 Manifest 里的权限组合很敏感。比如 READ_SMS + INTERNET + BIND_ACCESSIBILITY_SERVICE 这个组合，几乎一定会触发高置信度警告。如果业务上确实需要这些权限，考虑拆分功能模块，用多个 APK 分别申请，或者把敏感权限延迟到运行时动态请求，而不是在 Manifest 里静态声明。

渠道包的差异化。对于通过官网直接分发的 APK，可以在文件名和下载页面文案上做一些"合规暗示"，比如包含"official"、"verified"等关键词。没有证据表明 Play Protect 会解析文件名，但用户的心理预期会影响他们对扫描延迟的容忍度。更实际的做法是，在下载页面明确告知"安装时可能出现系统安全提示，请点击'更多信息'→'仍要安装'"，提前做心理建设。

长期看，如果业务依赖侧载分发，需要评估 Google 政策的持续收紧趋势。Android 16 的预览版里已经出现了 "enhanced verification" 的实验性 flag，传闻会把前置扫描和 Google Account 的信誉分绑定，新账号或者信誉低的账号面临更严格的扫描。这个改动如果落地，对匿名分发和一次性账号场景是毁灭性的。

一个未解的问题

前置扫描的技术实现里，有一个细节让我始终想不通。

云端查询返回的 LOW_CONFIDENCE_THREAT 响应，在本地是如何渲染成 UI 的？我抓包看到的响应体是 protobuf 格式，解析后的字段包含风险等级和建议动作，但具体的警告文案、按钮颜色、甚至是否允许用户强制继续安装，这些决策逻辑是在 GMS 客户端里硬编码的，还是可以通过服务器配置动态下发？

如果是后者，意味着 Google 可以在不更新任何客户端代码的情况下，远程调整侧载体验的"恶劣程度"。今天允许你强制安装的应用，明天可能因为服务器配置变更而变成不可绕过。这种"远程可变的本地策略"在 Android 安全架构里并不新鲜（Google 的 SafetyNet 和 Play Integrity API 都是类似模式），但用在应用安装这个基础操作系统功能上，边界感很模糊。

我在 GMS 的反编译代码里找到了 OctarinePolicyEngine 类，它确实从 safebrowsing.googleapis.com 拉取一个名为 octarine_policy 的配置包，包含各风险等级对应的 UI 表现规则。这个配置包的更新频率是每天一次，静默后台拉取。换句话说，Google 每天都在微调全球 Android 设备的侧载体验，而用户和开发者对此毫无感知。

这种设计的"合理"解释是，安全威胁的形态在快速演变，静态规则不够用。但同样的逻辑可以用来辩护任何远程控制行为——反正都是为了你好。问题在于，谁定义"好"，谁监督"为了你好"的过程，谁为误判负责。这三个问题，Google 都没有给出让人满意的答案。

Android 的开放性曾经是它区别于 iOS 的核心卖点。现在 Google 在用一种更隐蔽、更技术官僚的方式，逐步收拢这个开放性。前置扫描不是终点，而是一个信号：在"安全"的话语体系下，平台控制可以无限细化，直到开放的名义和封闭的现实之间的缝隙，小到用户根本意识不到自己曾经拥有过选择。