EDLA、GMS 与 AOSP 对比：各术语对企业设备意味着什么

直接回答

EDLA、GMS 和 AOSP 并不是三种对等的 Android 操作系统。AOSP 是开源的平台基础。GMS 是一套单独授权、附加在 Android 构建版本之上的 Google 应用与 API 集合。公开的 OEM 及合作伙伴资料将 EDLA 描述为符合条件的企业设备类别用以搭载该 GMS 层的一条授权路径。本次审查未找到 Google 公开发布的、涵盖资格条件、测试项、费用及机型范围的通用 EDLA 规范；应将 EDLA 视为一项需要 OEM 或相应授权方就具体机型提供证据支持的主张。

从分层模型出发，而非三选一

宣传册上的标签能告诉采购方该问哪些问题，但无法回答项目中的所有问题。应将这些术语视为不同的层级。

各层级之间的关系

以 EDLA 为卖点宣传的设备本质上仍然基于 Android。这不是一个“EDLA 还是 GMS 还是 AOSP”的选择题。应当询问该设备使用的是哪个 Android 构建版本、Google 层是否经过合法授权、哪条路径适用于该设备类别，以及项目需求是否已得到验证。

AOSP 意味着什么

AOSP 概览描述的是公开可用、可修改的 Android 源代码，设备制造商可据此创建各类变体。Android 兼容性计划则另行要求满足相应的兼容性定义文档（CDD）和 CTS 才能实现 Android 兼容性。这说明 AOSP 可以作为平台基础，而兼容性是一项需要额外证据支持的状态。它并不能证明 GMS 授权、应用行为、企业管理、更新，也不能证明某个 AOSP 构建版本仅限离线使用或仅限私有应用使用。应确定具体的构建版本、分发与云端依赖、兼容性证据、应用测试、管理路径及生命周期责任方，而不是把“AOSP”当作一套完整的架构来接受。

GMS 意味着什么

Google 将 Google Mobile Services（GMS）定义为一套经授权、不属于 AOSP 组成部分的 Google 应用与 API 集合；该集合的具体内容会因国家/地区可用性与要求而有所不同。Google Play services 是供 Google SDK 使用的设备端服务层，并不等同于全部的 GMS。一项合法的 GMS 主张能够表明存在一个经授权的 Google 软件层，但并不能证明所有必需的 Google 应用、SDK、账户流程、受管应用渠道或 Play Integrity 判定结果都能在目标应用和市场中正常工作。

• 梳理所需的应用、API、账户、分发渠道、后台服务、离线行为及完整性校验调用清单，并在报价的构建版本上进行测试。
• 不要将已过时的完整性校验要求带入新项目简报：Google 表示 SafetyNet Attestation 已于 2025 年一月全面下线。
• 应记录并测试生产环境应用的 Play Integrity 实现方式，而不是从设备标签推断其状态。

EDLA 意味着什么——以及公开证据未曾说明的内容

明基（BenQ）的 EDLA 说明文章将 EDLA 描述为使智能白板等企业解决方案能够内置 GMS 的机制，而 Kuori 的合作伙伴页面则描述了一项面向兼容 GMS 的商用显示设备的 EDLA 合作关系。Google 公开的 Android Enterprise 合作伙伴页面将部分设备计划的要求引导至合作伙伴资料或商务联系人，而未发布通用的 EDLA 规范。这些供应商与合作伙伴来源证明了围绕符合条件企业设备类别使用已授权 Google 服务的既有市场实践，但并不能证明 Google 的私有合同条款、普遍适用的资格、其他供应商的状态，或每一款自助终端、显示设备、终端机、手机或平板电脑的状态。

• 应将明基和 Kuori 的说明视为供应商/合作伙伴层面的描述，而非 Google 官方计划条款。
• 应要求提供一份声明，明确列出具体机型、SKU、Android 版本、构建版本、目标市场、主张责任方及相应证据。
• 不应将宣传册措辞或可见的 Play 商店图标视为充分证据。

EDLA 何时适用

本文审阅的公开 EDLA 案例主要集中在交互式显示设备与商用显示设备领域。这支持了当供应商在手机或平板电脑等常见路径之外的企业设备类别中提及 EDLA 时提出相关询问的做法，但并不能确立一份完整的合格设备清单。对于常规手机、平板电脑或手持设备，应询问其实际出货构建版本是否合法获得 GMS 授权并通过 Play Protect 认证。该项检查只能证明一种已观察到的认证状态，而无法证明 EMM 行为、更新期限、区域核准或现场工作流程。应针对机型/SKU/构建版本记录该结果，然后参考 GMS 与 AOSP 部署决策指南，评估应用、管理、配置及生命周期的适配性。

在报价或样机决策前应用五道关卡

无论是以 EDLA 为卖点宣传的显示设备、常规的 GMS 手持设备，还是基于 AOSP 的行业终端，都应使用这些关卡。每道关卡都会生成一份记录，可在项目转化为采购承诺之前接受测试或质疑。

1. 1锁定设备基线：记录外形规格、制造商、具体机型及区域 SKU、Android 版本、固件/构建版本号、安全补丁级别以及任何模块化计算单元。
2. 2审计应用与服务依赖关系：列出所有必需的 Google 应用、SDK、账户流程、分发渠道、后台服务和离线行为，并对实际应用进行测试。
3. 3核实相应的授权证据：明确主张责任方以及其覆盖的具体机型/构建版本/市场；将 AOSP 源代码使用、Android 兼容性、Play Protect 认证、GMS 授权与供应商所述的 EDLA 状态分别区分开来。
4. 4单独验证管理与注册流程：明确所有权模式、EMM、DPC 或代理程序、应用渠道、自助终端（kiosk）要求、配置路径、账户模型及恢复流程。
5. 5确认区域与生命周期：记录国家/地区可用性、更新责任方、操作系统及安全支持声明、OTA 路径、重置行为、更换路径、已知限制及重新验证触发条件。

将 Android Enterprise、EMM、零接触配置（Zero-Touch）与 AER 区分开来

Google 的 Android Enterprise 概览描述了 EMM 控制台、设备端策略组件与受管 Google Play。AOSP 的设备管理概览记录了设备所有者（device owner）、配置文件所有者（profile owner）、DPC 及策略框架等概念。Android Enterprise Recommended 要求是一项独立的、按版本发布的项目信号。因此，授权、管理架构、配置和 AER 是彼此独立的证据层级。

认可证据，而非标签

在批准样机之前，应收集能够随设备一同进入量产阶段的非保密证据。样机应证明所需的工作流程，而不是标签所暗示的每一项能力。

明确责任分工

这是一套规划模型，而非一份通用合同。Vantora 可以协调平台可行性评审，帮助将各项主张转化为可测试的需求，但不会授予 Google 授权、认证 EDLA 设备、运营客户的 EMM 租户，也不会承诺每一款机型都存在可行的授权路径。

申请平台可行性评审

请提供一份经脱敏处理的项目简报，包含设备类别、候选机型/SKU、目标国家/地区、数量范围、Android 构建版本、应用依赖项、所需的 Google 服务、管理技术栈、更新预期及验收优先级。初步评审无需提供最终客户名称或私有授权资料。Android 设备配置方法指南可帮助确定下一步的管理与注册决策。