定制启动器、Kiosk 模式与 MDM 对比：您需要哪一层？

简要答案

这三个术语描述的是同一套技术栈中的不同层级，而不是互相竞争的产品。定制启动器改变的是用户界面——用户看到的主屏幕，以及在设备上的导航方式。Kiosk 模式把设备限制在单一任务或一组既定应用之内，做法是在已将设备策略控制器（DPC）设为设备所有者的设备上启用锁定任务模式。MDM 或 EMM 是设备群策略层，负责设备注册、下发和变更策略、分发应用并报告合规状态。在这三层之下还有第四层：系统级 OEM 集成，通过 OEMConfig、厂商管理 API 或固件层工作实现，公开策略 API 未开放的控制项就位于这一层。多数项目会同时使用多个层级，因此真正有用的问题不是选哪一个，而是每项具体需求属于哪一层——以及该层究竟能强制执行这项需求，还是仅仅把它显示出来。紧接着还有第二个问题，本页后文会给出答案：最终配置是在预配阶段一次性写入设备，还是在设备群的整个使用周期内保持远程托管。

四个控制层，而非三种产品

需求往往以句子的形式提出——“它只能运行我们的应用”“它必须看起来像我们的产品”“我们以后需要修改白名单”“用户不得进入设置”。这些句子分别属于不同的层级，而多数设备项目的失效模式，正是把某项需求放在了无法强制执行它的层上。体验层就是启动器：屏幕显示什么，点击会去到哪里。任务限制层是锁定任务模式：设备被固定在哪个应用中，哪些系统 UI 元素仍可访问。设备群策略层是 DPC 及其背后的管理平台：注册、用户限制、应用分发、远程命令和报告。系统层则是 OEM 在标准策略接口之外开放的一切——扫描器与按键重映射框架、固件静默更新控制、特权应用权限、重置后的配置保持。厘清某项控制究竟属于 Android Enterprise、EMM、OEM 还是启动器，正是 OEM/MDM 依赖矩阵的用途；而是否要动用系统层，则是 MDM 与定制 Android ROM 对比讨论的主题。顺序很重要：能够强制执行某项需求的最轻量层级通常就是正确的层级，因为每向下一层都会增加验证时间、收窄候选设备清单，并引入新的重新验证触发条件。

• 体验层——定制启动器：用户看到什么，以及如何导航
• 任务限制层——锁定任务模式 / Kiosk：设备被固定在哪个应用中
• 设备群策略层——作为设备所有者的 DPC 加上 EMM 控制台：允许什么、可以改什么
• 系统层——OEM 集成、OEMConfig 或固件：公开策略 API 未开放的控制项

定制启动器改变了什么

定制启动器替换默认的主屏幕应用，重塑用户进入设备时看到的界面——显示哪些应用图标、它们之间如何导航、品牌呈现，以及首个内容入口。它属于体验层：它决定设备的外观与使用感受，而不是设备在技术上被允许做什么。在设备所有者配置下，DPC 可以把该启动器设为主屏幕 intent 的持久首选处理程序，因此它在预配阶段即被应用，而不是留给用户自行选择，首次开机时也不会出现选择对话框。正是这一个细节，把可交付的启动器与用户可以随手离开的启动器区分开来。启动器还可以带来品牌之外的实际运营价值——班次开始时的检查清单、便于戴手套操作的单个大按钮、显示同步状态或电池健康度的状态条、按站点而非按账户设定的默认语言。启动器做不到的是阻止任何事情。它只是呈现了更少的选项，并没有移除底层的那些选项。凡是必须经得住有意为之、或仅仅出于好奇的用户的限制，都必须在策略层上表达，然后在样机上确认，而不是从截图上想当然。

• 带有品牌元素的主屏幕，展示经过筛选的一组应用图标
• 围绕工作流程设计的导航和内容入口
• 由 DPC 在预配阶段设为默认主屏幕处理程序，而非由用户选择
• 仅涉及体验与品牌——其本身并不构成控制边界

Kiosk 模式与锁定任务模式真正控制什么

Kiosk 模式是锁定任务模式在实际运营中的叫法，这是一项由设备所有者授予的框架能力——从 Android 9 起，在关联用户和配置文件上也可以由配置文件所有者（profile owner）授予，不过企业自有的专用硬件通常仍会预配为设备所有者。DPC 把允许进入锁定任务模式的应用包加入白名单，设备随后被固定在该应用之内，或是由应用自身进入该模式，或是由管理平台代其应用 Kiosk 配置；Google 在专用设备的锁定任务模式文档中说明了该机制。除固定本身之外，策略还决定哪些锁定任务功能仍然可用——主屏幕键和概览键、通知面板、全局操作菜单、锁屏、状态栏中的系统信息。单应用 Kiosk 适合只做一件事的设备；多应用配置则在一组获准应用之上提供受管的主屏幕界面，Android Management API 会根据所需形态，将其表述为 kiosk 安装类型或受管 Kiosk 启动器。有两条限制值得尽早说明。锁定任务模式会阻止白名单之外应用包的活动，但它不会管束获准应用内部发生的事情，因此内嵌的 web view、文档渲染器或帮助页面仍可能暴露策略并未打算开放的导航路径——而且，如果为了让工作流程正常运行而放行了文档选择器之类的系统处理程序，那么该处理程序能够触及的一切也随之变得可达。此外，锁定任务模式是设备所注册的托管模式的一项属性——模式本身是另一个决策，参见专用设备与全托管 Android 设备对比。这些限制可通过 MDM/EMM 配置，并仍需在所选硬件和构建版本上通过技术验证。

• 单应用 Kiosk：面向只执行一项任务的专用设备
• 多应用 Kiosk：在受管主屏幕界面之后开放一组既定的获准应用
• 锁定任务功能决定哪些系统 UI 元素仍可访问
• 从获准应用内部发起的 intent 是最常见的绕过路径，务必测试

设备群策略层带来了什么

MDM 或 EMM 在设备群规模上运行。它通过约定的预配路径完成设备注册，应用用户限制和配置文件，分发并更新应用，向发布了托管配置的应用下发配置，报告资产清单与合规状态，并发出锁定、重启或重置密码等远程命令。启动器和 Kiosk 策略塑造的是单台设备，而设备群策略层决定这一状态如何应用到数百台设备上，并在此后持续保持最新。大多数硬性限制都位于这一层，而不在别处：阻止从未知来源安装、禁用安全模式启动、阻止用户自行恢复出厂设置、限制用户可修改的设置范围、控制调试访问权限。应用级限制通常也在这一层——发布了托管配置的浏览器可以由 EMM 下发白名单或黑名单，但仅限其开发方实际开放的字段，这正是浏览器限制应当尽早测试而非提前承诺的原因。可用的控制深度取决于 OEM 和平台，并且因管理平台而异，因此某项控制在 API 文档中存在，并不意味着它一定出现在您已授权的控制台中，或存在于您所采购的构建版本上。

• 通过约定的预配路径完成注册，此后在每次签入时应用策略
• 用户限制：未知来源、安全模式启动、恢复出厂设置、设置范围、调试
• 应用分发、版本控制和托管配置下发
• 资产清单、合规状态，以及锁定或重启等远程命令

只有系统级集成才能带来什么

有些需求在上述三层上都无法解决，因为相应的控制并不属于标准的 Android Enterprise 策略接口。典型例子包括硬件按键重映射、扫描器与 RFID 触发行为、为私有应用授予特权权限、在设备群其余部分更新时冻结某个固件版本、控制充电底座或外设总线，以及在重置后保留配置。这些都归 OEM 所有，实现途径包括 OEMConfig——由厂商发布、经标准 EMM 下发的托管配置架构——由定制代理程序调用的厂商管理 SDK，或平台层面的固件开发。对设备项目而言，其实际后果是：这一层会比任何其他因素更早地收窄候选设备清单，需求不再是“一台 Android 平板”，而变成“一台在该构建版本上开放此项控制的厂商所生产的 Android 平板”。它同时带来维护义务，因为厂商框架的版本演进独立于 Android 本身。应把系统层工作视为一次有明确责任方的主动升级，只有在某项需求确实无法在更高层满足时才启用，并将其记录为带有重新验证触发条件的已知限制，而不是当作已解决的事项。

• OEMConfig——无需定制代理程序，通过标准 EMM 下发厂商设置
• 厂商管理 SDK——在 OEMConfig 无法覆盖时由定制代理程序调用
• 固件或平台层开发——最重、可移植性最差的方案
• 谨慎升级：这一层会收窄候选设备清单，并增加重新验证触发条件

静态策略与远程托管：第二个维度

选择层级回答的是控制什么。另一个独立的问题决定这些控制如何维持：策略是在预配阶段一次性写入设备，还是在设备的整个使用周期内保持远程托管？两种都是合理的设计，而在这一点上判断失误的代价，往往要到交付数月之后才会显现。静态配置的设备把已验收状态从预配工作台一起带走。预配阶段应用启动器、锁定任务配置、应用集合与各项限制；此后设备在没有常态化管理关系的情况下运行。没有任何东西需要签入，不需要许可证也能继续工作，也不需要有管理员去看管控制台。代价落在变更上：新增一条白名单、更新一个应用或修正一项设置，都意味着重新预配、退回设备或上门服务，而这笔成本会随现场每一台设备成倍放大。远程托管的设备与 EMM 租户保持着实时关系。策略在中心侧受版本控制，并在下一次签入时应用；应用可原地更新；合规状态可见；设备丢失后可以远程锁定。代价落在依赖上：这一设计预设了网络通路、有效订阅，以及移交之后有一位指名的租户责任方。最后这一点最常无人认领。租户绑定在企业身份之上，必须有人保管管理员凭据、续订许可证、审批应用，并在设备脱离合规状态时作出响应。如果在批次放行之前没有指定这位责任方，设备群恰恰会在最需要管理的时刻变得无法管理。离线情形应当给出明确答复，而不是靠假设。从不签入的设备并不会丢失策略——它会保留最后一次成功应用的状态并继续运行。它失去的是此后的每一次变更：新策略、应用更新、权限撤销和远程命令全都排队等待、永远不会送达，而控制台上显示的最后在线时间已经过期，很容易被误认为设备状态正常。站点确实无网络的项目，最终往往采用混合方案：一套足以独立满足运营要求的静态基线，再加上在有连接的地方引入中心化管理的注册流程。这种混合方案必须是写明的设计并约定离线窗口，而不是在第一次策略变更时才发现的意外。

为什么仅有启动器不构成控制边界

在没有设备所有者策略支撑的情况下安装的定制启动器，通常都能被绕过。用户可能通过安全模式、通过修改默认主屏幕应用的设置路径、通过获准应用发起的 intent，或者通过恢复出厂设置回到原生界面——因为启动器只是在表面作画，并没有移除任何能力。强制力来自设备所有者层及其开放的 OEM API：阻止安全模式启动和未知来源安装的用户限制、决定哪些系统 UI 得以保留的锁定任务配置、决定用户是否有权擦除设备的重置策略。防绕过是策略层的属性，而不是主屏幕的属性。这一区别值得用平实的措辞写进需求文档，因为“锁定”一词在设计师和管理员心中含义相差极大。实践中诚实的表述是一对陈述：启动器定义预期路径，策略层封堵非预期路径。两者随后都要经过测试，而在所选硬件上无法封堵的路径，应记录为已接受的例外，而不是悄悄略过。

• 没有设备所有者策略的启动器，可通过安全模式或设置路径绕过
• 普通的恢复出厂设置会移除设备所有者，并使设备退回原生界面
• 可强制执行的限制位于设备所有者、用户限制和 OEM API 层
• 启动器定义预期路径；策略封堵非预期路径

常见的组合架构

实践中各层是叠加使用的，少数几种组合就能覆盖大多数部署。启动器加设备群策略，得到的是既有品牌界面、又可中心化管理和更新的设备——面向客户或现场作业人员的设备通常就是这种形态。锁定任务模式加私有分发的应用，构成面向单一工作流程的专用设备，启动器的角色实际上被固定的应用吸收。当某项硬件行为需要调整、而定制代理程序又显得代价过高时，OEMConfig 可通过标准 EMM 下发厂商设置。定制代理程序则弥补公开策略 API 留下的空白，代价是承担持续的维护义务。而静态预配的基线——无论之后是否再做注册——适用于无法保证网络连接的设备群。这些都不是产品档次，而是按需求逐条选定的组合，同一个项目中也可以并存多种——一次部署常常会为共享轮班设备采用完全锁定的版本，同时为主管配置更宽松的方案。

• 启动器加设备群策略：可中心化管理的品牌界面
• 锁定任务模式加私有应用：面向单一工作流程的专用设备
• OEMConfig：通过标准 EMM 下发厂商设置
• 定制代理程序：弥补公开策略 API 未覆盖的空白
• 静态预配基线：无需管理连接即可维持的已验收状态

需求到层级的决策矩阵

把每项需求映射到相应的层级，可以让投入保持适度，也让验收讨论变得具体：下表中的每一行，都对应一个负责强制执行它的机制，以及一项证明它成立的测试。该表仅供参考——具体型号、Android 版本、管理平台和应用所对应的执行路径，需在验证阶段确定并在任何承诺之前记录在案，因为同一项需求会因所选硬件开放的能力不同而落在不同的层上。

在受版本控制的样机上验证每一层

层级映射在样机验证之前只是一个假设。受版本控制的样机是把确切型号与区域 SKU、Android 版本与固件构建、应用包与版本、策略版本与预配路径全部固定下来的那台设备——从而使下面的每一项声明都挂在可复现的对象上，而不是挂在某个设备系列上。每一层产生的证据类型不同，把它们混为一谈，正是项目在批次阶段遭遇意外的原因。仅靠启动器的声明，诚实地测试起来是这样的：品牌主屏幕出现，图标正确，随后测试人员下拉通知面板、点进设置、更改默认主屏幕应用、进入安全模式启动，并执行恢复出厂设置。如果这些路径中有任何一条通向需求所禁止的地方，那么这项需求本来就不属于启动器层——它属于策略层，而验收矩阵记录的是机制，不是外观。任务限制的证据在设计上就是行为性的、对抗性的。样机不是靠应用能打开来证明的，而是靠它在重启、来电、通知、拔掉充电器、更新、强制停止和低电量关机之后仍然保持打开来证明的——同时还要有一条获准的主管退出路径，既对工作人员可用，又不至于变成通用的绕过手段。绕过测试应作为具名场景写入验收矩阵，并给出通过、不通过或有条件通过的结论，因为这些正是真实用户在头两周里就会找到的路径：安全模式启动、设置深层链接、分享面板、获准应用内的文件选择器、下载处理程序、跟随外部链接的内嵌 web view、无障碍服务、USB 调试，以及恢复出厂设置本身。设备群策略的证据是控制台证据加上一次变更测试：设备以预期的身份和构建版本出现，已批准的那个策略版本正是被应用的版本，并且有意发布一次策略变更，观察它在约定时间窗内到达设备。系统层的证据最狭窄，也最依赖具体型号——某项厂商控制在这个构建版本上要么可用、要么不可用，而结果绑定在一个可能变动的固件版本上。所有无法封堵的问题都要写下来，而不是丢掉：已知限制库的存在，正是为了让残留的绕过路径、有条件通过的结论和依赖责任方对审批人保持可见。结果本身的结构——场景、预期行为、实测行为、结论、责任方——遵循样机验收矩阵。随后的批次预配是复现已验收状态，而不是重新发明：相同的预配路径、相同的策略版本、相同的应用构建，逐台对照参考样机检查，并在某台设备出现偏差时执行停止规则。这就是把一台可用的样机变成一个项目的过程，项目规模通常从 500 台左右起报价，并在项目内部先用二十到一百台设备的试点批次，在真实条件下确认层级决策，然后再预配其余设备。

• 把每一项层级声明都绑定到同一台受版本控制的样机——型号、SKU、构建版本、应用、策略、预配路径
• 通过尝试离开来测试启动器：通知面板、设置、更改默认主屏幕、安全模式、恢复出厂设置
• 在验收矩阵中记录绕过场景，给出通过、不通过或有条件通过的结论并指定责任方
• 用一次真实变更验证设备群策略：发布一个策略版本，并观察它在约定时间窗内到达
• 复现而非重新发明——批次预配重复已验收状态，一旦某台设备出现偏差即停止

层级模型的已知限制

层级模型是一种规划工具，而不是保证，有必要说明它在哪些地方不再整齐。实践中各层并不能完全分离：锁定任务配置会改变启动器的行为，应用更新可能把某项控制从应用层挪到策略层，而 OEM 的具体实现也可能在相同 Android 版本上偏离文档描述的框架行为。可用性自始至终取决于 OEM、Android 版本、EMM 和硬件，因此在某一型号上确认过的控制，在其后继型号上并不算已确认。

• 托管配置只开放应用开发方已发布的字段——EMM 无法凭空创建这些字段。
• 锁定任务模式阻止的是白名单之外的应用包，而不是获准应用内部的导航；web view 和被放行的系统处理程序仍是常见的绕过路径。
• 标准的恢复出厂设置会移除设备所有者；能否保持取决于预配路径以及必须逐型号确认的 OEM 行为。
• 远程操作要求设备能够接收并执行命令；离线或损坏的设备需要另行准备恢复路径。
• 固件和应用更新会使行为在层级之间迁移，应触发重新验证，而不是假定行为延续不变。
• 控制台文档描述的是平台能力，而不是您租户上已授权的功能集，也不是您确切构建版本上的实际行为。

先定层级，再定设备

纠正层级决策成本最低的时刻，是在选定硬件之前，因为决定候选清单的，层级远比规格表更关键。能在标准 Android Enterprise 策略上解决的需求，会让设备选择保持宽泛；而需要厂商管理框架的需求，则把范围收窄到少数几款型号，并附带持续的维护义务。请带着需求清单而不是产品设想前来：用户必须看到什么、设备必须被禁止做什么、交付之后哪些内容需要变更、设备群是否具备网络连接、由谁持有管理租户，以及正在讨论的数量区间。Vantora 会把每一条需求映射到体验层、任务限制层、设备群策略层和系统层，说明哪些是强制执行的、哪些只是外观呈现，并在作出任何承诺之前记录残留限制——各个检查点的顺序见经验证的 Android 设备部署如何运作，集成工作本身则见应用、MDM 与 Kiosk 集成。