GMS 与 AOSP 企业设备对比：部署决策指南
先根据应用和市场需求选定平台服务路径，再在具体设备构建版本上验证管理、配置、更新及恢复能力，然后才批准部署。
- 作者
- Vantora Device Rollout Team
- 发布于
- 更新于
这是一个两维度的决策
当应用或部署依赖 Google Play services、受管 Google Play、Google 零接触配置（zero-touch）或标准的 Google 支持的 Android Enterprise 路径时，应从一款经过 Play Protect 认证的具体 GMS 候选机型入手，然后在目标 SKU 和构建版本上核实相应的服务及注册资格。只有当上述依赖不存在或可被替代，且分发、管理、签名、OTA、维护、恢复及生命周期责任已明确分配并验证完毕时，才应考虑非 GMS 的 AOSP 路径。
支撑这一选择的六项已公开事实
这些来源确立了有用的平台边界，但并不能把某个机型系列、某个标志或供应商的声明变成特定项目的验收证据。
| 已验证事实 | 能够证明什么 | 无法证明什么 | 采购方或验收行动 |
|---|---|---|---|
| AOSP 是用于构建 Android 变体的公开源代码；GMS 是一套单独授权、不属于 AOSP 组成部分的 Google 应用与 API 层。 | 平台源代码与 Google 服务是两项彼此独立的决策。 | 无法证明某个 AOSP 构建版本正在得到维护，也无法证明报价方案中的 GMS 构建版本已获得授权。 | 记录具体的构建版本及其 Play Protect 和 GMS 相关证据。 |
| Google Play services SDK 客户端在运行时会调用设备上已安装的 Google Play services 应用。 | 仅安装 APK 并不等同于完成了依赖关系审计。 | 无法证明生产环境应用实际使用了哪些 SDK，也无法证明其失败时的行为表现。 | 应测试服务缺失、被禁用、版本过旧、受限及离线等各种状态。 |
| Google 将 Android Enterprise 解决方案描述为由 EMM 控制台、Android Device Policy 及受管 Google Play 组成。 | 标准的 Google 支持路径拥有明确命名的组成部分。 | 无法证明每一款 EMM 都会开放全部控制项，也无法证明同一套技术栈会存在于非 GMS 构建版本中。 | 锁定具体的 EMM、管理模式、应用渠道、策略及构建版本。 |
| AOSP 文档记录了受管配置（managed provisioning）的框架流程及 DPC 的职责。 | 非 GMS 构建版本可以实现 Android 管理的基础功能。 | 无法证明某个具体构建版本上存在一条完整、安全、有维护保障或已获认可的生产路径。 | 应要求提供设置向导或 DPC 相关证据、应用分发方式、重置、恢复流程及责任方信息。 |
| Google 的零接触注册（zero-touch enrollment）要求具备合格的设备、启用了 Play services 的 GMS、受支持的 EMM、由授权经销商创建的账户、已分配的配置以及设置阶段的网络连接。 | 零接触配置是一条特定的供应链与服务路径。 | 无法证明某个机型系列、经销商报价或门户账户能够覆盖具体的设备单元。 | 应核实设备标识符、分配情况、配置、网络、初次开机的干净状态及恢复能力。 |
| Android 兼容性需要满足相应的 CDD 和 CTS 要求，而发布的镜像及 OTA 更新包则依赖受控的签名密钥。 | 兼容性和发布权限是可测试的证据类别。 | 无法证明 GMS 授权、更新期限、市场核准或客户工作流程的验收结果。 | 应在合同中分别约定兼容性、授权、签名、更新、恢复及验收方面的证据要求。 |
平台服务与设备管理是两项独立的决策
应先选定应用和市场所需的平台服务路径，再在具体构建版本上验证管理、配置、更新及恢复方案的实现情况。无论 GMS 还是 AOSP，本身都无法证明零接触配置、EMM 支持、更新条款、离线行为、安全性或二维码配置能力。
GMS 与 AOSP 企业设备对比
此处所说的 GMS 路径，是指经过授权且通过 Play Protect 认证的量产构建版本；AOSP 路径则是指经过刻意界定范围、不含已授权 GMS 层的量产构建版本。
| 决策维度 | 已授权的 GMS 路径 | 非 GMS 的 AOSP 路径 | 批准前需要的证据 |
|---|---|---|---|
| 应用运行时 | 提供经过认证的具体构建版本上所具备的 Google Play services API。 | 依赖 Google 服务的功能必须缺失、被替代，或设计为能够安全降级失败。 | 依赖项清单以及端到端的应用测试。 |
| 应用分发 | 在管理架构支持的情况下，可以使用受管 Google Play。 | 需要项目自行定义分发与更新渠道，并明确相应责任方。 | 干净安装、更新、回滚、签名及离线状态下的测试结果。 |
| 企业管理 | 可以使用受支持的 Google 支持的 Android Enterprise 和 EMM 路径。 | 需要经过验证的框架、DPC 或代理程序、策略、应用渠道及支持路径。 | 具体的所有权模式、管理组件、策略及设备/构建版本的测试结果。 |
| 配置（Provisioning） | 使用具体的 Google 支持路径所支持的特定管理状态配置方法。 | 需要经过验证的 AOSP 受管配置方案，或其他由项目自行定义的实现方式。 | 能够从预期的干净状态可重复完成的注册流程。 |
| 平台证据 | Play Protect 认证、具体机型/SKU/构建版本、GMS 状态及相应的 EMM 支持情况。 | 构建版本标识、组件清单、应用与管理路径、签名责任方及发布基线。 | 已记录在案的证明材料，而不仅仅是标志或供应商声明。 |
| 系统控制权 | 受到经认证的 OEM 构建版本、公开 API、受支持的 OEM 功能及授权条件的限制。 | 只有在项目具备可行的 OEM/BSP、权限及签名访问权限时，控制权才可能更深入。 | 经过授权的实现路径及可测试的需求。 |
| 操作系统生命周期 | 固件发布及支持条款仍由 OEM 或平台所有方掌控。 | 必须由明确的构建版本责任方负责集成、签名、测试、分发及支持各版本发布。 | 补丁策略、发布责任方、OTA 路径、恢复流程及停止支持的记录。 |
| 重置与恢复 | 重新注册以及应用/策略的恢复仍需要经过验证。 | 重置行为及恢复方式可能完全取决于具体项目。 | 恢复出厂设置、重新注册、更新失败及恢复流程方面的测试。 |
在选定硬件之前先审计应用
不要仅凭“可在 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审计应用：Google API、身份验证、分发、更新、离线行为、外围设备及后端依赖关系。
- 2定义管理方案：所有权模式、EMM/DPC、策略、应用渠道、配置方式及重置状态。
- 3锁定候选方案：具体机型、区域 SKU、Android/固件构建版本、GMS/Play Protect 状态及补丁级别。
- 4指定责任方：应用及系统签名、OTA、安全修复、回滚、支持及生命周期终止。
- 5测试样机：工作流程、注册、策略、更新、离线状态、重启、重置及恢复。
- 6决策：在进入批量试产之前，接受已获证据支持的基线、更换路径，或重新界定范围。
在批准样机前要求提供证据
样机验收应描述的是一套可复现的系统，而不仅仅是一台曾经成功开机的设备。Vantora 可以协调设备选型、应用与管理方案验证、配置、质量保证及交付；应用团队负责应用行为，EMM 提供商负责其所支持的实现方案，OEM 或经授权的构建版本责任方掌控固件与签名，而客户或集成合作伙伴则负责批准风险与验收结果。
| 证据类别 | 样机记录应体现的内容 |
|---|---|
| 设备基线 | 具体机型、区域 SKU、构建版本指纹、Android/固件版本、补丁级别及组件基线。 |
| 平台与应用 | 针对 GMS 构建版本的 Play Protect/GMS 证据，或针对非 GMS 构建版本的组件/责任方记录；首次运行、权限、身份验证、工作流程、离线状态、安装及更新方面的测试结果。 |
| 管理与恢复 | EMM/DPC 注册、策略、自助终端（kiosk）或限制、报告功能、支持访问权限，以及恢复出厂设置、重新注册、更换和恢复方面的测试结果。 |
| 发布责任 | 明确的发布及支持责任方、构建版本规格、发布说明、验收记录及已知限制。 |
申请可行性评审
请提供一份经脱敏处理的项目简报，包含预期的设备类别、目标市场、数量范围、应用现状、对 Google 服务的依赖关系、EMM、配置路径、生命周期预期及验收优先级。初步评审无需提供最终客户名称或商业细节。如果拟采用的硬件超出常规手机、平板电脑或手持设备的 GMS 路径范围，且供应商提出了 EDLA，请参阅 EDLA、GMS 与 AOSP 对比指南，以了解该项独立的授权与设备类别问题。
常见问题
AOSP 设备仍然能够被管理吗？
有可能。Android 包含设备管理及受管配置相关框架，但具体的构建版本必须提供可正常工作的设置向导、DPC 或代理程序、所有权模式、策略、应用分发、网络连接、恢复及维护路径。仅凭“AOSP”本身并不能作为完整管理方案的证据。
GMS 能否在设备生产完成之后再行添加？
不应基于这一假设进行规划。GMS 是单独授权的，量产构建版本、机型、OEM 路径、Android 兼容性及 Play Protect 状态都必须对其提供支持。非正式地安装 Google 应用，并不能将一个非 GMS 构建版本变成一台经过合规授权的量产设备。
GMS 能否保证获得 Android Enterprise 支持及操作系统更新？
不能。应确认预期的管理模式、EMM 功能集、注册方式、区域 SKU 及构建版本，并单独核实 OEM 在 Android 版本、安全补丁、固件、恢复及停止支持方面的承诺。
对于离线或高度受控的设备而言，AOSP 是否总是更好的选择？
不一定。GMS 设备同样可以支持离线业务工作流程，而 AOSP 构建版本也可能仍然依赖网络及外部服务。只有在其依赖关系、控制权、生命周期及商业模式都经过刻意支持并得到验证的情况下，才应选择 AOSP。