什么是定制 Android 设备？

实用定义

定制 Android 设备，是指配置围绕某项具体业务需求被固定下来、而不是留给个人用户自行个性化的智能手机或平板电脑。基础硬件通常是一款已经量产、成熟可靠的 Android 手机或平板电脑；改变的是它之上的那一层——品牌外观、预装软件、默认使用体验、管理策略，以及在少数项目中还包括固件或元器件。设备到手即具有明确用途：开机直达组织配发它所要承担的那个工具，执行组织约定的各项限制，并且在批次中的每一台设备上都以同样的方式做到这一点。当人们问什么是定制 Android 设备时，多数人指的正是用途优先于个性化。

Takeaway. 优先走能够验证的最轻路径。层级编号不能保证不动固件，也不能保证自动继承补丁。开机标志且固件不动是待确认的条件，不是保证。

为什么可复现性属于定义的一部分

简短定义往往会丢掉的那个属性——在每一台设备上都以同样的方式——恰恰决定了项目的成败。技术人员能在工作台上做出一次的配置，是一次演示。能写进设备配置规范、在受版本控制的样机上得到验证、对照验收矩阵签署、并在批次记录下被复现的配置，才是一个设备项目。两者的工程内容可以完全相同；差别在于这个状态是否可复现、是否有证据。因此，本站通篇使用的工作定义刻意收得很窄：定制 Android 设备是一个已约定的设备配置版本——机型与区域版本、Android 版本、固件基线、应用集合、策略集合、包装和市场假设——它已在样机上通过验证，并在批次记录下被复现。下文描述的是这个配置版本里可以包含什么、每一部分依赖谁，以及哪一篇指南负责相应决策。逐项能力的视角见 Android 设备定制能力。

四个定制层级

把定制理解为层层叠加的层级，而不是一份可以随意点选的菜单，会更有帮助。每上一层都会增加能力、成本和验证工作量，也会改变必须参与的人：预装是软件工作，策略是 EMM 工作，而固件改动是 OEM 的工程工作，还要附带 OEM 的交付周期。多数项目在前两三层就能收敛，第四层约束最多，需要针对所选硬件逐案验证。下表最好只朝一个方向读：有用的问题不是可选的最深层级是什么，而是满足需求的最轻层级是什么。一个通过品牌定制、应用预装和 Android Enterprise 策略就能交付的项目，比需要固件分支的项目构建更快、支持成本更低、更新更容易，而且能继续沿用 OEM 的安全补丁流，不必自己承担这份责任。深度是成本，不是卖点。如果某项需求确实无法靠策略满足——重新映射硬件按键、移除某个无线模块、超出标准策略面的系统级限制——那才是更深层级发挥价值的地方，相关取舍见 MDM 与定制 Android ROM 对比。

获批样机必须证明什么：五项成果

层级描述的是可以改变什么。成果描述的是项目结束时组织真正拥有什么；对第一次为定制设备写需求的人来说，成果这个视角更有用。每个已验收项目最终都落实为五项成果——候选设备清单、应用就绪构建、策略可控配置、通过验收测试的样机和批量预配置交付——而且每一项都在链路中的特定节点得到证明，而不是在提案里被宣称。因此，这五项成果也是检验任何供应商（包括我们自己）的诚实标尺：如果供应商说不出每项成果在哪里被确认、由谁签字，那么这项成果只是意向，而不是交付物。下表把每项成果对应到部署链路中它不再只是一句声明的那个节点，以及负责其背后决策的指南。

五项成果各自的含义

候选设备清单回答的是：哪一款机型、哪个区域版本、哪个 Android 版本、多长的支持期限。它得到证明的时刻，是设备配置规范指定了一款同时通过应用、地区、外设和生命周期筛选的硬件，而不是某个产品目录条目单看起来合适。应用就绪构建回答的是：整个项目赖以存在的那套软件到底能不能跑起来——安装、首次启动、登录、权限、离线行为、后台任务和更新路径，在冻结的应用版本上、对照冻结的固件基线逐一测试。策略可控配置回答的是：每一项限制由哪一层控制来实现——启动器改变用户看到什么，专用设备锁定改变系统允许什么，EMM 策略改变设备群强制执行什么，固件则是最后手段。通过验收测试的样机回答的是：签署了什么；以及同样重要的，哪些内容被记录为已知限制，而不是被悄悄寄望于侥幸。批量预配置交付回答的是：已验收状态能否在量产设备上复现并可追溯，而不是在十八个月后凭记忆重建。

三个项目，三种不同深度

把层级和成果放进具体形状里更容易把握，下面是三个——它们是常见项目形态的示意组合，不是具名客户。一次约一千台的现场服务部署通常停在第三层：一款当前的中端 OEM 手机、预装工单应用、用专用设备策略把手机锁定在该应用加相机与通话上，品牌定制只做开机 Logo 和包装。固件完全不动，OEM 的安全补丁流照常运行，日程的大部分花在样机而不是构建上——要证明应用在重启后仍保留权限，也要证明技术员无法从应用跳进浏览器。一次规模相近的公共部门部署，在幻灯片上看起来一模一样，其实不然：它的配置必须为采购和审计留下文档并且可复现，于是工作量转移到证据上——由具名验收方签字的结果、把序列号或 IMEI 区段追溯回获批样机的批次记录，以及写下来而不是指望它自行消失的已知限制。这正是约 1,000 台受控部署的形状，也是在体验层构建的组织项目的形状——后者把组织标识、预装应用和以专注为默认的首屏，变成了一份可构建的设备规格，而没有动固件。第三种形状属于少数情况：受限用途项目必须在策略够不到的层级上移除或禁用某项能力。它会走到第四层，同时带来 OEM 工程、更长的样机周期和目标市场文档问题——ODM 与 OEM 的区别也正是在这里不再只是名词之争。三者的五项成果相同；不同的是深度、责任方，以及需要多少证据。

每一层各自的代价

深度用三种货币计价，其中只有一种会出现在报价单上。第一种是日程：每加一层，样机在批次 staging 之前就要多证明一件事。第二种是证据——更深的构建不只是要多测，而是要多记录：固件基线、回归结果、补丁计划。第三种是责任，它比项目本身活得更久：到第三层为止，OEM 继续发安全补丁，设备群直接继承；到了第四层，这份继承不再自动成立，必须有人在部署的整个生命周期里承担它。所以取“够用的最浅层级”是一个维护决策，而不是预算上的妥协。数量档、定制深度、文档范围和样机轮次对报价的影响，远大于物料清单——具体数字在MOQ、成本与工期，其他项目已经撞上的限制则收在已知限制库。

定制 Android 设备与个性化的消费级手机

个性化一部消费级手机，是个人为自己更改消费级设置——壁纸、应用、账户、通知偏好。这些改动可逆、没有文档，换一台机器就无法复现，除非把每一步手工重做一遍。定制 Android 设备是为规模部署而构建的，其中可复现性和集中控制比任何单个用户的偏好都更重要。真正的实务差别是这份一致性，而不是开机画面上的 Logo；正是它让数千台规模的设备群可以由一支小团队支持：当每一台设备都出自同一个已验收配置版本时，一通支持电话谈的是一台设备，而不是这台机器究竟运行着十一种可能配置中的哪一种。

已部署设备的状态从何而来

两者的机制差别在于配置来自哪里。消费级个性化存在于用户可以自行撤销的用户设置里。已部署的定制设备则从一次预配流程和注册时下发的管理策略中获得状态——通常是把设备策略控制器（DPC）设为设备所有者——因此配置由平台反复重申，而不是靠拿着设备的人记住。在预配路径支持的情况下，一次重置可以把设备恢复到约定基线，而不是回到空白的消费级状态；不过这一行为取决于预配路径和 OEM，属于样机应当实测、而非默认成立的事项之一。这也解释了为什么注册时选择的所有权模式，比大多数功能清单所暗示的更重要：工作资料、公司自有设备上的工作资料和全托管设备所暴露的控制范围并不相同，而专用设备是在全托管设备的基础上进一步收窄到一个应用或一小组应用。

每项决策实际在哪里作出

定义页不应试图把它提到的每个决策都一并定下来，本页刻意没有这么做。下面每个问题都有一篇负责它的指南，其中完整写明了取舍、平台依赖以及样机必须产出的证据；这里的一句话答案是给刚接触这个话题的人做定位用的，不能替代决策本身。按顺序读下来，这五个问题也大致构成一条先后次序：是否真的需要定制设备，排在选哪一层控制之前；控制层的选择，排在平台路线之前；而商务形态——数量区间、样机轮次、文档范围——才是把这一切变成报价和日期的环节。

• 我们到底需不需要定制设备？现成设备加 EMM、轻度配置的设备和完整定制配置，是三种截然不同的投入——见定制与现成 Android 设备对比。
• 用策略还是改固件？标准 Android Enterprise 策略能覆盖大多数限制；定制 ROM 则要自己背上补丁和维护负担——见MDM 与定制 Android ROM 对比。
• 选 GMS 还是 AOSP？一边是 Google 服务和受管 Google Play，另一边是不含服务的构建版本，其注册、应用分发和更新前提都不相同——见GMS 与 AOSP 企业设备对比。
• 该用哪一层锁定？启动器改变用户看到什么，专用设备锁定改变系统允许什么，EMM 策略改变设备群强制执行什么——见定制启动器、Kiosk 模式与 MDM 对比。
• 成本多少、什么时候能交？数量区间、定制深度、文档范围和样机轮次对报价的影响，比物料清单更大——见MOQ、成本与周期。

常见业务应用场景

凡是组织为完成某项明确工作而配发硬件、而不是随手发放通用手机的地方，都会出现定制 Android 设备。各行业的模式高度一致：有人要为设备做的事负责，拿着设备的人并没有挑选它的权利，而一台配置不一致的设备所带来的代价，是支持电话、审计不通过或整班工时损失，而不是轻微的不便。现场服务团队和物流作业使用它们，是为了让员工开机直接进入正确的工具，并在整个班次中留在其中。公共部门项目使用它们，是因为配置必须可记录、可复现，以满足采购和审计要求，而不只是在演示当天能用。教育和社群项目使用它们，是为了把单一的学习或会员体验呈现在用户面前并保持住。零售和内容平台使用它们，是为了让一个应用实际上就等于整台设备。这些场景的共同点不是一份功能清单——而是验收问题在每种情况下都完全一样：这个确切的配置版本，装在这个确切的机型上，在第一台设备和第两千台设备上是否都以同样的方式完成约定的工作？

• 现场服务与物流——在锁定的工具集上运行检查、勘测和配送工作流程。
• 公共部门——带部门品牌、策略可控的设备，用于公务和现场场景。
• 教育与社群项目——把聚焦的学习或会员体验设为默认。
• 零售与内容平台——开机直接进入单一应用或内容入口的设备。

什么时候你并不需要定制 Android 设备

一个诚实的定义页，必须写上答案是“不需要”的情况。定制设备项目的报价从 500 台左右起，因为固定工作量——规格、样机、验收、批次记录——不会随订单数量缩小；低于这个门槛，同样的结果通常用现成设备加一份 MDM 订阅更划算，而且在样机轮次之前说出来，比在之后才发现便宜得多。另外三种“不需要”更安静，因为它们看上去像设备问题，其实不是。每一种都值得刻意排除：一个本质上属于应用的需求，会跟着项目一路走到第四层，并且在那里依然没有被解决。

• 低于约 500 台——改用现成设备加 EMM 配置；更大项目内部 20-100 台的试点批次属于另一回事。
• 只有品牌，没有应用、没有策略、也没有部署计划——那是一次采购行为，而不是一次设备构建。
• 你现在部署的设备群今天就能施加的限制——先在手上的硬件上测试策略，再考虑换硬件；见把主流 Android 手机用作受控项目设备。
• 真正长在应用里的缺口——离线行为、权限和后台任务首先是应用决策，其次才是设备决策；见应用就绪设备检查清单。

哪些事情不能想当然

没有两个设备配置版本是完全一样的，因此假定在一款机型上观察到的能力可以照搬到下一款，是有风险的。可用的 Android 版本、安全补丁的时间范围、在用的是 Google 移动服务还是不含服务的 AOSP 构建、OEM 源码开放的深度，以及该机型的量产寿命，全都带有 OEM 依赖，必须针对具体硬件核实，而不能凭产品系列名判断。有一条假设值得单独点名：GMS 并不是 Android 本身的属性。Google 服务和受管 Google Play 是通过一个经过授权、通过兼容性测试的构建版本才到位的，其底层要求发布在 Android 兼容性定义文档中。不含服务的 AOSP 构建需要另一条管理和应用分发路线，这条线索由 GMS 与 AOSP 企业设备对比 接着展开。而最强的那些管控又依赖于把设备策略控制器设为设备所有者，这通常要求设备处于干净的开箱或恢复出厂设置状态，而不是已经用个人账户设置好的状态——在已配置好的消费级手机上事后加装设备所有者，一般是做不到的。

一张表看懂术语

定制设备项目早期的混乱，多数来自术语而不是工程：两个人用同一个词指代不同的控制范围，直到样机阶段才发现。下表固定本站使用的术语，更有用的是指出每个词在哪一刻不再是定义，而变成必须有人去证明的结果。

暗含前提的术语

这个领域里有几个日常用语，悄悄带进了只有样机才能澄清的前提。专用设备并不是一种独立的管理模式：它是被锁定到一个应用或一小组应用的全托管设备，因此继承了设备所有者的能力，Google 在专用设备文档中记录了这一模式。锁定任务模式如何处理状态栏、通知、系统弹窗和恢复路径，会随 Android 版本和 OEM 实现而不同，这正是它应当出现在验收矩阵里、而不是写进一句规格描述的原因。同样，EMM 只能设置应用开发者确实通过受管配置公开出来的配置项；任何管理平台都无法凭空创造它们，而一个完全没有公开配置项的第三方应用，就需要另辟蹊径。目标市场文档、无线频段和进口方责任按国家逐一评估，而任何超出已记录标准行为的内容，在纳入项目之前都需要经过技术验证。

定制设备项目通常如何推进

定制设备项目不是下单之后等着意外发生。它要走过六个清晰可见的检查点——项目简报、设备配置规范、已验证样机、验收矩阵、已预配批次和受管部署——每个检查点都有明确的输入、明确的输出材料和指定的验收人。正是这三项特征让整条链路可审计；项目一旦延误，几乎总是因为其中之一被留成了默认默契，于是没人就“样机获批”的含义达成一致，或者没人被指定去作出这个判断。这些检查点也正是“什么是定制 Android 设备”这个问题内部所藏的答案：设备就是设备配置规范所写的样子，由样机所展示的内容来证明，并由批次记录所追溯的方式来复现。完整走查——每个检查点的输入、输出材料和验收责任方，以及逐步累积成配置资料包的那些材料——见经验证的 Android 设备部署如何运作，同一条链路的交付侧视角见定制 Android 设备开发流程。

1. 1项目简报——用户、应用、目标市场、限制要求、数量区间和时间安排；在需要保护合作伙伴关系的地方作脱敏处理。
2. 2设备配置规范——候选机型清单、GMS 或 AOSP 路线、Android 版本、应用预装清单、启动器与策略设计、包装、标签和已知限制。
3. 3已验证样机——在真实硬件上、对照冻结的应用与策略版本完成的配置版本，并以发行说明准确记录构建了什么。
4. 4验收矩阵——应用、策略、网络、重置和包装行为的通过、不通过与有条件通过结论，由具名验收决策方签署。
5. 5已预配批次——按已验收版本准备的量产设备，并在批次记录中以序列号或 IMEI 追溯回样机。
6. 6受管部署——移交支持边界、更新责任归属、保修路径、备机政策和重新验证触发条件。

定制设备项目中哪些可以变通，哪些不能

深度可以自由变通。在成熟机型上做品牌加应用的订单，能较快走完规范和样机；而固件层或文档量大的配置版本会在验证上耗掉数周，也理应如此；规划周期是典型范围，需按项目逐一确认。不能变通的是次序。样机未验收，不预配批次；规范未签署，不制作样机；简报无人评审，不撰写规范。跳过一个检查点并不能消除它对应的风险，只是把发现这个风险的时机推到了现场，而那正是修复代价最高的地方。在一台评审样机上发现的 Kiosk 退出漏洞，是一条工程记录；同样的漏洞出现在两千台已预配设备上，就是一起事故，届时已验收基线、批次记录和支持边界都得同时重新打开。

从需求出发，而不是从功能清单出发

定制设备项目最常见的走偏方式，是它一开始就是一份购物清单——一个 Logo、一个 Kiosk 模式、一个预装应用——而不是一项需求。功能清单无法被测试，需求可以。把谁在用这台设备、他们必须能做什么、必须不能做什么、在哪里使用、发往哪些市场、预计多少台描述清楚，才能把对话变成可行性评估真正能回答的东西；实践中，这也会在需求被写下来之后剔除本来就没人需要的定制，从而缩短项目周期。关于数量：项目报价从 500 台左右起，在量产批次确定之前，项目通常先从 1-3 台评估样机和约 20-100 台的试点批次开始。低于这一门槛，用 MDM 订阅配置一台现成设备通常是更经济的路线，而早点把这话说出口，比走完一轮样机之后才发现要便宜得多。方案需求分析负责把需求转化为候选设备清单和一份带责任方的待决问题清单，而设备配置规范模板则是这些答案最终落地的格式。

Takeaway. A boot logo can be an OEM asset setting. It is not automatically a system-image change.

Send a redacted brief. We reply within 1 business day.