Android 专用设备与全托管设备有何区别？

简要答案

在 Android Enterprise 中，全托管设备和专用设备都属于公司自有硬件，也都需要在预配时把设备策略控制器（DPC）设为设备所有者。真正起决定作用的正是设备所有者这一点：组织控制的是整台设备，而不是与个人用途并存的工作容器。两者的差别在于用途意图，而不是权限高低。全托管指的是配发给具名人员的纯工作设备，用户登录后在一组由组织控制的应用中开展工作。专用设备——这一模式至今仍被广泛沿用旧称 COSU，即公司自有单一用途——就是把同一台全托管设备收窄到一项任务或一小组任务，通常无人值守、多人共用或面向客户。因此，专用设备一定是全托管设备；全托管设备却不一定是专用设备。工作资料是第三种形态，且性质截然不同：此时 DPC 是配置文件所有者，管控止于工作容器，设备的个人侧不受组织策略约束。Google 的 Android Management API 文档把这些视为彼此独立的管理模式，而真正具有约束力的区别在于所有权：设备被预配为设备所有者还是工作资料，由注册路径固定下来，事后无法在控制台中更改。在设备所有者范围之内，全托管与专用只是策略问题，而不是预配问题——这正是本指南后文所述模式变更代价差异如此悬殊的原因。本指南统一沿用这套术语，使写入采购规范的模式，对 EMM 管理员、应用团队和签署订单的审批方而言含义一致。

全托管意味着什么

全托管设备是公司自有硬件，管理平台在其上充当设备所有者，组织可以对整台设备下发策略。最常见的画面是配发给员工的工作手机或平板电脑：用户登录后即可使用通过受管 Google Play 分发的一组工作应用，而设置、网络和应用安装都遵循组织策略，而不是个人偏好。设备所有者是 Android Enterprise 在不改动固件的前提下所能提供的最大标准管控范围——通常涵盖静默安装与卸载应用、为受管应用授予权限、限制添加账户或侧载、Wi-Fi 与证书配置、系统更新策略以及远程锁定或擦除。某一款手机上实际可用的管控项取决于 OEM、Android 版本和 EMM，因此我们把这类设备描述为策略可控、集中管理，并在目标硬件上确认具体管控能力，而不是照抄控制台菜单里的功能清单。

• 公司自有设备，注册时把 DPC 设为设备所有者
• 对整台设备下发策略，而不是使用单独的工作容器
• 用户账户可以访问由组织控制的工作应用
• 根据组织策略限制个人用途
• 管控范围因 OEM、Android 构建版本和 EMM 而异——须逐款型号确认

专用设备意味着什么

专用设备是被锁定到既定用途的全托管设备，通常不绑定具名用户。这种形态适用于 Kiosk、面向客户的终端、按班次共用的设备，以及全天只运行一项任务或一小组任务的一线工具。由于专用是全托管的子集，它继承了同样的设备所有者管控能力，再通过锁定任务模式把运行环境收窄到本职工作：由 DPC 声明哪些应用包可被固定，并在受支持的构建版本上声明设备处于锁定状态时，状态栏、主页键、最近任务和通知等系统功能是否仍然可用。Google 关于专用设备与锁定任务模式的指南说明了平台开放了哪些能力，EMM 随后只呈现其中一部分。由此带来两个实际结果。其一，专用设备往往无用户——不登录任何 Google 账户，应用由 EMM 下发，而不是由用户自行下载。其二，锁定的严格程度取决于策略和启动器，而不是模式名称本身；因此同一模式既可以做成严格的单应用 Kiosk，也可以做成宽松的四应用班次设备。这类配置可针对 MDM/EMM 进行配置并限定于既定用途，其行为须在所选硬件上确认后，批次方可获批。

• 单一用途或范围严格限定的任务集
• 通常无用户、多人共用、无人值守或面向客户
• 锁定任务模式固定已批准的应用包，并精简系统 UI
• 它是全托管模式中被锁定的子集，而不是另一个权限层级

工作资料处在什么位置——以及个人用途为何会改变答案

这两种公司自有模式经常被拿来与第三种形态比较，而后者的行为方式与它们完全不同。在员工自有设备上，工作资料让 DPC 成为受管容器的配置文件所有者：工作应用、工作账户和工作数据都在容器之内，组织可以擦除该容器，而容器之外的一切——启动器、个人应用、相册、设备的恢复出厂设置行为——仍归设备主人所有。这是刻意的设计，而不是有待绕开的缺陷。这也意味着员工自有的形态无法实现整机管控，无法把设备固定为 Kiosk，也无法在不擦除硬件的前提下转换成 Kiosk。当项目简报写着“我们想要 Kiosk 行为，但员工同时也会私人使用这些手机”时，正是必须当场把规范敲定、而不是继续拖延的时刻。Android Enterprise 确实提供了公司自有设备上的工作资料——通常简称 COPE——其预配仍然经过设备所有者，随后再在其上创建工作资料。从 Android 11 起，这种形态的个人侧受到刻意保护：管理员无法获取个人应用清单，整机权限被限定在资产管理类的管控范围内，例如系统更新策略、设备标识符、恢复出厂设置保护，以及一组明确界定的限制项。具体范围取决于 Android 版本和 EMM，必须与审批方所理解的约定内容逐条核对。如果整台设备都服务于这项任务，全托管或专用才是诚实的答案；如果员工确实需要在公司硬件上进行个人使用，应当写入规范的就是公司自有设备工作资料，验收讨论的重点也随之转向：在隐私边界之下，哪些管控仍然有效。我们的托管与受控 Android 设备项目正是从这个决策出发，而不是预设答案。

• 员工自有设备上的工作资料：配置文件所有者，仅限容器，无整机管控
• 公司自有设备工作资料（COPE）：先按设备所有者预配，再创建个人侧受保护的工作资料
• 全托管与专用：纯工作用途硬件，整机策略管控
• 无法在员工自有设备的工作资料上搭建 Kiosk

策略与用户体验差异

两种公司自有模式差别最大之处，在于站在设备前的人所看到的内容。全托管的员工设备通常保留可识别的主屏幕和登录之后的多应用环境，设置项是被精简而不是被移除。专用设备则依靠锁定任务模式固定单个应用或一个小型受管启动器，屏蔽退出入口并隐藏大部分系统 UI，使公众或换班间隙的操作员无法离开既定任务。专用设备显示一个还是多个应用，是策略决定，而不是模式本身的属性。真正实现可见锁定效果的那一层——受管启动器、EMM 自带的 Kiosk 策略，或由 DPC 直接驱动的锁定任务模式——则是另一个需要明确作出的选择：定制启动器、Kiosk 模式与 MDM 对比完整讨论了这一层的决策。我们把具体的锁定程度视为可配置、且须在目标设备上验证的事项，因为围绕通知、对话框、无障碍提示和 OEM 定制层的系统 UI 行为，往往正是 Kiosk 逃逸路径的所在。

• 全托管：用户登录、多应用、设置项经过精简但仍可见
• 专用：以锁定任务模式固定单个应用或一个小型启动器
• 专用设备可按策略配置为单应用或多应用
• 启动器/Kiosk 的实现层与模式选择是两个独立决策

可到达设备所有者的注册路径

两种公司自有模式都通过相同的 Android Enterprise 路径预配为设备所有者，之后再由 EMM 下发的策略加以区分。这是本页最具实用价值的一条机制性事实：设备以何种方式离开设置向导，决定了它是否成为设备所有者，而能够设定设备所有者的窗口非常狭窄。实际操作中，该路径必须在处于恢复出厂设置或未开箱状态的设备上运行，且必须在添加个人账户之前、设置流程完成之前——这正是注册属于预配台上的作业，而不是现场用户在办公桌前拆箱后自行完成的原因。零接触注册是能够规模化的路径，但它首先是一项供应链条件，其次才是技术条件：符合条件的设备必须通过获授权的零接触经销商采购并登记到您的账户，且在首次开机前完成配置分配。在设置向导中出示 QR 码是常见的手动替代方案，也是批次预配的常规路径；NFC 以及在设置向导中输入 DPC 标识符在受支持的构建版本上依然有效，但更适合小批量或特定 OEM 场景。每条路径都有各自的前提条件，它们往往不会在需求界定阶段暴露，而是在预配环节悄然失败——欢迎页面的网络、正确的经销商账户、真正干净的设备。Android 设备预配方式对接入方式本身作了更深入的对比；下表则换一个角度解读这些路径：各自能到达哪些管理模式，以及通常会在哪里出问题。

事后更改模式的真实代价

并非每一次改变主意都代价高昂，关键在于分清哪些是。在全托管与专用之间移动通常只是策略变更：设备本身已经是设备所有者，因此把一批设备收紧进锁定任务模式、加上受管启动器，或把某台终端放开回多应用配置，都只是下发策略并重启应用，而不需要送回预配台。进出工作资料形态则是另一个量级的工作。设备所有者只能在上文所述的预配窗口内建立，因此处于个人自有工作资料状态的设备无法被提升为全托管，只能恢复出厂设置并通过设备所有者路径重新预配。反向切换、以及两种公司自有形态之间的切换同样如此：把已交付的设备群从全托管改为公司自有设备工作资料，或者反过来，都意味着每台设备都要回到干净状态。在项目规模下，真正的代价不在于重置本身，而在于围绕重置的物流——从各站点回收设备、重新预配、重新记录序列号和 IMEI，并在变更后的基线上重跑验收。正因如此，管理模式应当在首批设备预配之前就写入设备配置规范；也正因如此，评估样机和二十到一百台的试点批次，才是发现模式选错的正确位置，而不是等到整个项目全部出货之后。此类项目的报价从 500 台左右起，因此在现场才发现的模式错误，其代价要按整支设备群的逐台处理次数来衡量。

• 全托管 ↔ 专用：通常只是策略变更，无需重新注册
• 工作资料 → 全托管：需逐台恢复出厂设置并重新预配
• 全托管 ↔ 公司自有设备工作资料：需逐台回到干净状态
• 现场重新预配消耗的是物流成本而不是许可成本——请在设备配置规范中确定模式

恢复出厂设置会对模式产生什么影响

管理模式并不是一项能够自行熬过擦除的属性。恢复出厂设置会把硬件还原为未预配的出厂状态，之后它能否重新回到受管状态，完全取决于当初的注册路径。零接触设备正是那个把差别显现出来的例外：由于分配关系保存在零接触控制台中并绑定硬件标识符，重置后的设备只要在设置期间连上网络，就会再次收到它的配置并自行完成预配。通过 QR 码、NFC 或 DPC 标识符注册的设备没有这种记忆——重置之后它就是一台普通零售设备，直到有人在预配台上把原有路径重复一次。策略可以降低意外重置的概率：设备所有者可以限制用户从设置中执行恢复出厂设置，恢复出厂设置保护也可以要求事后使用经批准的账户，但不同厂商的组合键恢复方式和 OEM 售后工具行为各异，必须在具体型号上核实，而不能想当然。对一次部署而言，这是一个验收问题，而不是冷知识问题。应当有意识地对样机执行重置并使其恢复，记录预期的最终状态，并为将来持有这些设备的人员写好恢复操作说明——因为在一支专用设备群中，“重置后自行回到 Kiosk”和“到达站点时是一台空白的消费级手机”之间的差别，就是一张支持工单和一次派人上门之间的差别。

• 重置会移除设备所有者；模式并不存储在硬件中
• 零接触会在下次设置且有网络时再次下发该配置
• QR 码、NFC 和 DPC 标识符路径需要在预配台上重复一次
• 重置限制和恢复出厂设置保护取决于 OEM 和具体型号

使用场景决策矩阵

在这些模式之间做选择，归结为三点：设备由谁持有、它整天在做什么、以及是否还有人需要用它做别的事。需要多个工作应用、需要登录、需要熟悉主屏幕的一线员工，指向全托管；Kiosk、巡检终端、教室成套设备或共用的零售终端，指向专用配置；还必须承担个人用途的设备，则同时排除这两者，指向公司自有设备工作资料。许多项目会同时运行多种模式——员工使用受管手机，同时面向公众的任务使用专用终端——只要每个设备组都有各自的策略集、各自的样机和各自的验收记录，这样做没有任何代价。下表仅供参考，而非硬性规定；适合您的硬件、应用和市场的模式，应在需求界定阶段确定，再在样机上得到验证。

把模式写进样机、矩阵和批次

在会议上敲定的管理模式只是一种意见；在预配台上复现出来的管理模式才是基线。在一次部署中，这个决策必须落进三份材料。受版本控制的样机要证明：具体型号、区域 SKU 和固件版本能够从干净状态出发、经由既定路径到达目标模式，并在到达之后按描述执行策略——包括重启之后，以及约定的重置场景之后。验收矩阵把这些记录为通过、失败或有条件的条目，并绑定到具体版本，而不是绑定到某人抽屉里的一台设备：到达的模式、使用的路径、锁定任务的应用包和功能项、允许的设置、已测试的退出路径、重置后的最终状态，以及仍然开放的已知限制。批次预配随后逐台复现已验收状态，并记录复现了什么——序列号、IMEI、注册确认、策略版本，以及与参考样机的 QA 比对——并对偏差设定停止规则。这一递进关系正是 MDM 就绪与部署就绪 Android 设备对比所划出的区别：能在控制台中看到的设备证明了管理能力，而获批进入批次的设备证明的是状态可复现。模式选择是这条链条中最早的输入之一，也是事后代价最高的一项，因此它应当在订购硬件之前就写入设备定制范围，而不是等设备落地之后。请提供目标设备或形态、应用、EMM、所需管控、目标国家和数量区间，可行性评估将确定该需求实际需要哪种模式、供应链能够支持哪条注册路径，以及在批次获批之前样机必须证明什么。