MDM 与定制 Android ROM：项目需要哪一层控制？

简要答案

MDM 或 EMM 在现有 Android 配置版本上应用受支持的策略；定制 ROM 则直接改变系统镜像。如果所选设备可通过策略满足要求，应优先采用 MDM。只有当要求超出该策略能力范围，且项目能够承担由此增加的更新、签名、测试和支持责任时，才应考虑 OEM、启动器或固件工作。

MDM 管理现有配置版本，定制 ROM 则改造配置版本

MDM 或 EMM 平台为管理员提供控制台、注册路径、设备与应用策略、资产清单以及受支持的远程命令，但它不会取代 Android。具体控制范围取决于设备的所有权与管理模式、Android 版本、OEM 实现、所选 EMM 以及相关应用。Google 的 Android Management API 预配文档清楚展示了这种差异：个人自有设备工作资料、公司自有设备工作资料、全托管设备和专用设备的控制范围并不相同。全托管和专用设备模式可支持广泛的仅限工作用途控制，包括将设备锁定为只运行一个应用或一小组应用，但所需行为仍必须在实际型号和配置版本上验证。“定制 Android ROM”是行业简称，并非 Android 的某个官方产品类别；本文指经授权、针对具体项目更改操作系统镜像或固件基线。这条路线可能适用于启动阶段体验、特权系统组件、受支持策略无法实现的限制、供应商硬件集成，或受控的固件/更新路径。它并不只是设置项更多的 MDM。

选择通常不只是二选一，而是在 MDM、混合方案与固件之间权衡

许多项目无需非此即彼。EMM 可负责策略管理，启动器负责塑造使用体验，OEM 集成则处理依赖硬件的功能。只有在其他层无法实现要求并通过验收时，才需要开展相应的固件工作。

将每项要求映射到足以满足要求的最低控制层

有意义的问题不是“哪个选项功能更强？”，而是“哪种受支持机制能够满足这项要求、经受相关故障场景的考验，并在计划生命周期内得到维护？”可先用 Vantora 的 OEM/MDM 依赖矩阵作为简明起点，再根据项目的具体设备、应用、EMM、配置版本和验收方法替换泛化标签。

何时应优先采用 MDM

如果所选管理模式提供所需策略，且设备通过样机验证，MDM 通常是改动最小的起始路线。它保留 OEM 支持的固件更新路径，将策略变更与操作系统发布分离，并为运营团队提供设备群管理界面。这并不意味着“MDM 无所不能”。Android Management API 策略参考中的设置受管理模式、Android 版本等支持条件限制。应用还必须定义项目所要设置的托管配置。因此，控制台中的一个开关只代表候选能力，不能作为验收证据。

何时有理由开展固件层工作

只有当某项强制要求无法通过受支持的管理方式、应用、启动器或 OEM 集成实现时，固件评估才是合理的；不能只是因为“定制 ROM”听起来更可控。批准这条路线前，应确认谁拥有获授权的构建权限、谁负责发布密钥、如何创建和分发更新、如何恢复或回滚配置版本，以及覆盖哪些设备型号版本。AOSP 的发布签名指南指出，已部署镜像需要妥善保护的发布密钥，OTA 包也必须使用系统所认可的密钥签名；这些是持续性的发布责任，而非一次性的工程细节。兼容性也需要单独的工作流：Android 兼容性计划要求 Android 兼容设备符合《兼容性定义文档》并通过 CTS，而可能涉及的 GMS 许可则是另一个后续步骤。在没有明确证据的情况下，不要假定修改后的配置版本仍能保持应用兼容性、获得 Google 服务的资格、区域准入或 OEM 保修权益。

生命周期成本与已知限制

公平的比较必须覆盖部署的完整运营生命周期。对于 MDM，应计入许可、租户与注册运维、策略维护、连接、支持，以及设备、Android、应用或 EMM 变更后的重新验证。EMM 可以管理其支持的更新策略，但不能决定 OEM 何时发布固件。对于定制 ROM，应计入源代码访问、工程开发、发布签名、OTA 分发、回归测试、安全维护、回滚、设备型号版本、支持，以及 OEM 继续维护该分支所需的商务条件。混合路线也必须为每个版本、缺陷、更新和恢复操作指定责任方。

选择路线前的验收问题

不要把抽象的“MDM”或“ROM”架构作为批准对象，而应批准有记录、有证据支持的基线。设备出现在 MDM 控制台中可以证明一项重要能力，但不能证明整个部署已经就绪；同样，成功刷入定制镜像只能证明该镜像能够启动，不能证明应用、管理、更新、恢复、区域适配性和批次流程都可接受。有关这一区别的进一步说明，请参阅 MDM 就绪与部署就绪 Android 设备对比。

• 正在测试的具体型号、区域 SKU、Android 版本、固件版本和安全补丁级别是什么？
• 哪些所有权/管理模式、EMM 租户、策略版本、注册方式和应用版本被纳入范围？
• 能否把每项所需控制映射到 Android Enterprise、EMM、应用、启动器、OEM 接口或固件，并为其指定一名责任方？
• 能否在代表性设备上从洁净状态重复完成注册或刷机流程？
• 所需应用、Kiosk、网络、外设、远程支持、重启、重置和离线场景是否均已通过测试？
• 应用更新、策略更新、OTA、固件重建、恢复出厂设置、型号替换或区域 SKU 变更后，会有哪些变化？
• 对于定制固件，谁负责源代码、构建产物、发布密钥、OTA 签名、回滚、安全修复，以及何时终止支持的决定？
• 已验收样机是否具备设备配置规范、发行说明、已知限制记录和可供量产复现的测试证据？

实用决策路径

Vantora 的作用是协助把这些层映射为一个可测试的设备项目，也就是什么是 Android 设备部署集成商？中所述的协调工作；它不会取代客户的 EMM 平台，也不会承诺在每个型号上都提供 ROM 层控制。应用、MDM 与 Kiosk 集成和 Android 固件与软件定制页面说明了如何界定这些路线的范围并根据前提条件进行验证。

• 写清结果，而不是指定机制——把“我们需要 ROM”改写成可测试的行为，例如“重启后，用户无法退出获批准的应用”。
• 锁定候选基线——明确型号/SKU、Android 配置版本、GMS/AOSP 路径、应用、管理模式、EMM、区域和外设。
• 先测试受支持的管理方式——确认满足要求的是实际策略，而不是根据功能列表作出的假设。
• 评估中间层——检查启动器、应用改动、OEM 托管设置、SDK 或获授权的预装能否弥补缺口。
• 只针对剩余要求启动固件可行性评估——确认访问权限、商务支持、签名、OTA、兼容性、安全维护、恢复和支持的责任归属。
• 在有明确版本记录的样机上验证所选架构——记录通过、失败、有条件和已知限制结果。
• 将已验收基线带入批次预配——当关键版本、组件或责任归属发生变化时，停止预配或重新验证。