GMS 与 AOSP 企业设备对比：部署决策指南

这是一个两维度的决策

当应用或部署依赖 Google Play services、受管 Google Play、Google 零接触配置（zero-touch）或标准的 Google 支持的 Android Enterprise 路径时，应从一款经过 Play Protect 认证的具体 GMS 候选机型入手，然后在目标 SKU 和构建版本上核实相应的服务及注册资格。对于实时通信应用，可使用 Android WebRTC 硬件选型指南，确保平台服务决策始终与其必须支持的摄像头、编解码器、音频、网络和持续通话证据相对应。只有当上述依赖不存在或可被替代，且分发、管理、签名、OTA、维护、恢复及生命周期责任已明确分配并验证完毕时，才应考虑非 GMS 的 AOSP 路径。

Takeaway. 能安装 APK 不是依赖审计。运行时、分发、管理和更新责任要分开确认。

支撑这一选择的六项已公开事实

这些来源确立了有用的平台边界，但并不能把某个机型系列、某个标志或供应商的声明变成特定项目的验收证据。

平台服务与设备管理是两项独立的决策

应先选定应用和市场所需的平台服务路径，再在具体构建版本上验证管理、配置、更新及恢复方案的实现情况。无论 GMS 还是 AOSP，本身都无法证明零接触配置、EMM 支持、更新条款、离线行为、安全性或二维码配置能力。

GMS 与 AOSP 企业设备对比

此处所说的 GMS 路径，是指经过授权且通过 Play Protect 认证的量产构建版本；AOSP 路径则是指经过刻意界定范围、不含已授权 GMS 层的量产构建版本。

Takeaway. Installing Play does not prove this build is licensed or that the deployment passed.

Common mistake. Installing Play does not prove this build is licensed or that the deployment passed.

Send a redacted brief. We reply within 1 business day.

在选定硬件之前先审计应用

不要仅凭“可在 Android 上运行”就选定平台。应审计实际的应用、SDK、身份验证流程、更新方式及失败时的行为表现。Google 说明 Play services SDK 会与设备上安装的 Play services 应用进行通信，因此未安装该应用的设备无法提供这一运行时环境。应在服务处于最新、不可用、被禁用、版本过旧、受限或离线等各种状态下测试生产环境应用，记录应用是否能够启动、完成身份验证、完成相应工作、进行同步，以及在失败时能否可恢复地降级。

• 梳理 Play services、推送、Maps、Google 登录（Google Sign-In）、Play Integrity、Play 授权及其他 Google API 依赖项清单。
• 将应用分发视为一项独立的依赖项，并为签名、版本定向、发布、更新及恢复分别指定明确的责任方。
• 在具体受支持的管理架构有此要求时，使用受管 Google Play；针对非 GMS 构建版本，则应定义一套受控的替代方案。

Android Enterprise 适用于何处

Google 将标准的、由 Google 支持的 Android Enterprise 解决方案描述为由 EMM 控制台、Android Device Policy 及受管 Google Play 组成。这条路径不应被泛化推广到每一款非 GMS 构建版本上。与此同时，AOSP 中同样存在 Android 管理的基础能力：其受管配置文档涵盖了设备所有者和配置文件所有者的使用场景，包括二维码、NFC 及云端发起的配置流程——前提是构建版本、设置向导及 DPC 提供了所需的相应行为。AOSP 本身并非天生不可管理，也并非天生不兼容二维码配置；真正的生产问题在于具体的 OEM 构建版本及管理组件能否提供一套完整、可维护的实现方案。

• 应将零接触配置视为一条针对特定合格设备、经销商、账户、配置、EMM 及网络连接的具体路径，而不是二维码配置或设备所有者配置的同义词。
• 应先选定管理状态，并参考 Android 设备配置方法指南验证确切的接入路径。

使用确切证据来验证兼容性与授权

不应将“已获 GMS 认证”视为一种普遍适用的保证。Google 表示，通过 Play Protect 认证的设备已经通过了 Android 兼容性测试，并可以在授权范围内搭载 Google 的专有应用。Android 兼容性计划采用兼容性定义文档（CDD）和 CTS 进行评估，但兼容性只能使设备具备申请 GMS 授权的资格，并不会自动授予该授权。

• 记录机型、区域 SKU、构建版本指纹、Play Protect 状态、Android 版本、补丁级别以及相应的 OEM 或 EMM 认证列表信息。
• 不应仅凭 Play 商店图标或供应商声明就推断授权状态。
• 不应仅凭认证就推断升级次数、补丁更新频率、停止支持条款或市场核准情况。

更深的平台控制权意味着更大的生命周期责任

AOSP 源代码的可获取性本身并不能提供板级支持包（BSP）、供应商二进制文件、特权权限、发布密钥、OTA 服务、回滚设计或维护人员。当项目确实需要某个特权组件、特殊硬件、私有生态系统或暂不可用的策略时，更深的控制权是合理的，但项目必须明确经过授权的实现路径及持续负责的责任方。应按设备、平台、需求、最小起订量（MOQ）、发布路径及可行性来界定 Android 固件与软件工作的范围，而不是假设可以访问每一个固件分支。

遵循一条有边界的选型路径

使用一套可重复的流程，避免项目将平台标签当作部署就绪的证明。

1. 1审计应用：Google API、身份验证、分发、更新、离线行为、外围设备及后端依赖关系。
2. 2定义管理方案：所有权模式、EMM/DPC、策略、应用渠道、配置方式及重置状态。
3. 3锁定候选方案：具体机型、区域 SKU、Android/固件构建版本、GMS/Play Protect 状态及补丁级别。
4. 4指定责任方：应用及系统签名、OTA、安全修复、回滚、支持及生命周期终止。
5. 5测试样机：工作流程、注册、策略、更新、离线状态、重启、重置及恢复。
6. 6决策：在进入批量试产之前，接受已获证据支持的基线、更换路径，或重新界定范围。

在批准样机前要求提供证据

样机验收应描述的是一套可复现的系统，而不仅仅是一台曾经成功开机的设备。Vantora 可以协调设备选型、应用与管理方案验证、配置、质量保证及交付；应用团队负责应用行为，EMM 提供商负责其所支持的实现方案，OEM 或经授权的构建版本责任方掌控固件与签名，而客户或集成合作伙伴则负责批准风险与验收结果。

申请可行性评审

请提供一份经脱敏处理的项目简报，包含预期的设备类别、目标市场、数量范围、应用现状、对 Google 服务的依赖关系、EMM、配置路径、生命周期预期及验收优先级。初步评审无需提供最终客户名称或商业细节。如果拟采用的硬件超出常规手机、平板电脑或手持设备的 GMS 路径范围，且供应商提出了 EDLA，请参阅 EDLA、GMS 与 AOSP 对比指南，以了解该项独立的授权与设备类别问题。