主流 Android 手机能否成为受控项目设备？

测试前先明确定义候选设备

“主流”描述的是一个商用产品系列，而不是它的所有权状态。本指南针对的是新采购或已恢复出厂设置的组织自有设备，而不是员工的个人手机。受控项目设备指的是一台具体手机，围绕一项明确用途，拥有记录在案的应用、策略、注册、恢复和验收状态。这是 Vantora 的项目术语，既不是 Google 的某种认证，也不是永久的产品等级。这个区分之所以重要，是因为几乎每一次令人失望的评估，都能追溯到一个从未被钉死的候选对象：测试的是一个型号名称，采购的却是某一台具体设备，而两者被默认为同一回事。一个手机系列可能横跨若干区域变体、两三种内存配置、一个带运营商定制的构建版本，以及一份在您测试的那个季度内变更过两次的出厂镜像。把候选对象记录到“可以据此重新下单”的颗粒度，后续流程才有稳定的对象可以挂靠证据。如果候选对象无法被界定到这个程度——因为渠道有什么货就卖什么货，或者供应商不肯锁定构建版本——这本身就是一项发现，它应当写进结论，而不是塞进脚注。

• 具体型号、区域或运营商 SKU、内存版本、供应商和采购渠道。
• Android 版本、固件版本、安全补丁、GMS/AOSP 路径和出厂设置状态。
• 应用包和版本、选定的 EMM、预期的所有权模式和必备控制项。
• 目标市场、网络、SIM/eSIM 假设、充电器、底座和所需外设。
• 已公布的更新与支持信息、替代型号、更换方案和备件。

Takeaway. 第二台设备或第二名操作者可以发现一部分漂移。覆盖范围仍取决于渠道、构建和风险。两台和一周不是服务周期。参考样机是不再改动的已验收配置，不是未配置的设备。

确认所有权与管理边界

整机管控取决于组织所有权，以及一条受支持的、从洁净状态出发的预配路径。AOSP 设备管理概览区分了配置文件所有者与设备所有者的管控范围，而现行的 Android 预配指南则把所有权、个人使用设置、令牌、方式和管理模式逐项写明。测试之前，先把允许的个人使用范围、目标模式、擦除权限、EMM 和注册路径固定下来。如果有人把员工自有状态当作整机管控，或者数据擦除权限尚未落定，就应当停下来。这条边界有一个属性决定了犯错的代价：所有权在设备预配时即被固定，事后无法从控制台切换。一台以带工作资料的个人设备身份完成设置的机器，不会因为有人改了某项设置就变成设备所有者模式的设备；它必须被擦除并重新预配。之后还能改变的，是在设备所有者预配之上应用的管理模式——在全托管配置与其专用、单一用途的子集之间切换属于策略变更，这两种模式的区别正是专用设备与全托管 Android 设备对比所讨论的内容。请记录您测试的是其中哪一种，因为在全托管配置下表现可接受的控制项，一旦设备被固定到某个工作流程，行为可能就不一样了。

执行六步具体设备转化流程

目标是一份范围明确的设备适配结论，而不是关于某个产品系列的笼统说法。请按预期量产所用的所有权模式、注册路径、应用、策略和采购渠道来执行该流程。对于零接触，要在这台具体设备上核实记录在案的经销商登记、配置、软件和网络前提条件，而不是假定同系列名称的零售设备就一定符合资格。有两条纪律，决定了这究竟是一套流程还是一场演示。第一条是顺序：每一步都以前一步通过为前提，因此故障会被记录在它发生的位置，而不是隔了三步之后才被重新发现、原因却已无从追溯。第二条是测试人员边做边写预配作业指导书，详尽到另一个人无需提问即可复现结果。这份指导书才是第二步和第三步的真正交付物——已验收状态只有在能被重建时才有价值——它也是第五步中第二位测试人员要遵循的依据。一次评估通常消耗一至三台设备：A 机承担包含破坏性演练在内的完整流程，B 机负责确认验证，第三台原封不动地留作参考样机，供日后批次预配比对。

1. 1锁定可订购基线：记录标签、具体 SKU、固件、补丁、供应商和预期渠道。
2. 2从洁净状态注册 A 机：记录重置条件、网络、租户、令牌或配置、策略及最终状态。
3. 3测试必备控制项和工作流程：应用安装、首次运行、身份验证、权限、离线使用、更新、外设和 Kiosk 退出路径。
4. 4对样机做破坏性测试并证明恢复能力：中断设置、重启、断开网络连接、重置或擦除，然后恢复到已验收状态。
5. 5用 B 机检验结果：按预期路径重复关键的设备身份、注册、工作流程、控制和恢复检查。
6. 6出具一页纸的设备适配结论，写明范围、证据、限制、责任方和重新验证触发条件。

如何在样机上测试每一类控制项

第三步是多数评估最薄弱的环节，因为控制台里出现的控制项，很容易被误当成在设备上真正生效的控制项。策略只是一个请求；已验收状态才是这一确切构建版本对它的实际处理结果。因此测试必须带有对抗性并且足够具体：对每一项控制，测试人员都需要掌握施加它的机制、检验它的动作、可以算作通过的可观察结果，以及真实用户最可能找到的绕行路径。每项控制归属哪一层——启动器、锁定任务模式、设备群策略还是 OEM 集成——在定制启动器、Kiosk 模式与 MDM 对比中已有说明；本页要解决的是在一台候选手机上把控制项验证出来。下文的大多数结果都由两个机制决定。锁定任务模式阻止的是白名单之外应用包的活动，因此真正要紧的暴露面从来不是被阻止的应用——而是获准应用内部的导航，以及工作流程当初需要放行的任何系统处理程序。而应用层的限制取决于开发方选择通过托管配置发布的字段；浏览器或扫描应用从未开放的设置，EMM 无法凭空创建。测试要在量产构建版本和量产应用版本上进行，从已验收状态出发，而不是在还开着开发者选项的实验机上进行，并把每一条结果都写成带责任方的判定。下表的行结构与样机验收矩阵一致，因此测试记录本身就成为验收记录，而不必事后再由谁誊抄一遍。若某项控制在这套硬件和构建版本上确实无法实现，那是一项需要记录的发现，而不是一项可以悄悄跳过的测试。

对样机做破坏性测试并证明恢复能力

一台只被开机并注册过的设备并没有被测试过；它只是被演示过。第四步之所以存在，是因为在现场真正造成成本的那些状态，没有人在实验台上主动制造过：设备在错误的时刻重启、丢失网络一整天、被好奇的用户重置，或者在固件更新之后带着不同的行为回来。这些状态都必须在 A 机上被刻意制造出来，并记录返回路径——不只是设备能否恢复，还包括恢复要花多长时间、谁能操作，以及恢复是否需要工作站、网络、凭据或返厂。恢复时长既是技术数字也是商务数字，因为它决定了日后整个设备群中一次现场故障的成本。这些演练要按顺序连贯执行，而不是当作勾选清单。把预配中途打断，看设备是能续上、卡在半托管状态，还是必须擦除后重新开始。反复重启，确认启动器、被固定的应用、策略和外设配对都能在无人触碰屏幕的情况下恢复。强制停止工作流程应用，并让电池耗尽关机。在约定的离线窗口内断开网络，确认限制依然有效、重新联网后排队数据可干净同步，并正确理解控制台上“最后在线”时间戳的含义——一条陈旧的记录并不能证明设备健康。然后尝试用户会做的那种重置，执行管理员会下发的授权擦除，并通过量产路径重新注册设备，看它究竟是真正回到了已验收状态，还是只回到了一个看起来相似的状态。任何无法在无人干预下恢复的项目，都是有责任方的限制，而不是小瑕疵，它应当在结论写就之前进入已知限制库。

• 打断预配：确认设备能够续上或干净地重来，而不是停在半托管状态。
• 重启、强制停止并耗尽电量关机：启动器、被固定的应用、策略和外设配对都必须在无人干预下恢复。
• 维持约定的离线窗口：限制持续有效、排队数据可同步，且陈旧的“最后在线”记录不能被读作合规证据。
• 尝试用户重置并执行授权擦除，然后通过量产路径重新注册，并与参考样机比对。
• 记录恢复时长、所需工具，以及是否需要返厂——这个数字日后决定现场故障的成本。

为什么一台设备永远不够：第二台设备的漂移测试

A 机是由理解这套配置的人配置的，而且配置那天固件恰好是某个特定版本。这正是它不能独自决定结论的原因。第五步会在第二台设备上重跑关键检查项——这台设备通过预期的量产渠道单独下单，并交给另一位只依据书面预配作业指导书操作的测试人员。这项测试有两个对象：设备，以及那份指导书。同一型号名下两台设备之间出现漂移是常态而非例外。出厂镜像会在不同生产批次之间变动，因此第二台设备到货时可能是另一个构建版本和补丁级别，并在首次开机后一小时内又被更新到第三个版本。区域和运营商变体预装的软件不同，偶尔连基带行为也不同。零接触登记是采购行为的属性，而不是型号的属性，因此通过另一条渠道买来的设备可能没有资格走 A 机用过的路径。A 机本身也已被评估过程污染——某个时点开启过开发者选项、添加过账户、测试中途接受过固件更新——而这些历史，设备群永远不会继承。发现漂移是一种结果，而不是测试失败。请记录差异是什么、该差异是否改变某项必备结果，以及能否通过更严格地指定 SKU、在预配作业指导书中锁定构建版本或限制渠道来加以控制。可以控制的差异会写成预配作业指令；无法解释的差异则成为候选设备保持“有条件”状态的理由。这一步也是批次预配的第一次预演：如果第二个人无法依据书面指导书复现已验收状态，那么这份指导书交到预配产线上也撑不住，而现在发现这个缺口，远比在项目已经承诺之后再发现便宜得多。

• 通过预期的量产渠道单独订购 B 机，而不是从同一箱货或同一批预留库存中取用。
• 把它交给另一位测试人员，此人手上只有书面预配作业指导书——受测的既是设备，也是这份指导书。
• 比对构建版本、补丁级别、预装软件、预配资格以及每一项必备控制的结果。
• 对每处差异分类：可以通过 SKU、构建版本或渠道规定加以控制，还是无法解释、因而构成一项条件。
• 留一台设备原封不动作为参考样机，供日后与已预配批次比对。

只用“接受”“有条件接受”“拒绝”——不留模糊表述

这份结论比整体部署批准要窄得多。它只适用于记录在案的设备、SKU、构建版本、渠道、应用、EMM 和市场范围。“有条件接受”是写得草率时破坏力最大的判定，因为它最容易被读成“通过”。有条件接受只有在同一处写明以下内容时才算诚实：哪些事项尚未关闭、由谁负责、用什么测试来关闭、期限是什么，以及如果没能关闭会怎样。它还必须写明在此期间哪些事不被批准——通常是不得承诺任何批量数量，也不得针对未关闭事项报出交付日期。一份没有指定责任方和日期的有条件接受，不过是换了个体面标签的拒绝，它会在数月之后以交付问题的形式浮出水面，而那正是承认它代价最高的时刻。还有两个习惯能让结论保持可用。给条件设上限：一个候选设备如果背着超出少数几项的未决事项，那就不是有条件通过，而是一次尚未完成的评估，诚实的做法是继续测试或更换候选设备。另外要把条件与限制区分开。条件是预期会关闭的，因此它有测试和期限；限制则是这台设备和这套配置的永久属性，由审批人睁着眼睛接受，它应当进入限制日志，并如实描述其行为，而不是被措辞软化。两者都要在结论签署之前写入记录，这样批准支出的人读到的，与执行测试的人读到的是同一份文件。

Takeaway. A camera block at device level is not the same control as per-app permission. Do not write both as one pass condition.

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

把 OEM 基线与项目状态分开

使用主流手机并不会让它变成定制硬件。OEM 依然拥有标准硬件、启动链、固件、更新渠道和生命周期。项目在此之上叠加受版本控制的应用、管理模式、策略、注册路径、预配作业指导书、测试记录、限制清单和责任方。系统更新策略在受支持时可以管控安装时机；但它无法让 OEM 或运营商发布固件，也无法保证变更之后工作流程依旧成立。实际后果是：已验收状态带有失效条件，而不是一个永久状态。OEM 出于消费市场考虑发布的一版固件，可能改变某项控制的行为、取消某种外设行为，或重置工作流程所依赖的某项设置，而这些在设备上报之前，管理控制台里一概看不到。请在出具结论的同时点名重新验证触发条件——Android 大版本升级、固件或补丁级别超出记录范围、应用版本变更、EMM 租户或策略版本变更、新的区域 SKU，或采购渠道变更——并说明每一项由谁盯守、触发后要重测什么。候选设备是针对某一状态被接受的，而不是被永久接受。

知道何时该拒绝或更换候选设备

当某项必备需求依赖于不存在的硬件、环境耐受能力、缺失的外设接口、OEM 未支持的控制、无法重复的恢复、不确定的区域供货或不足的生命周期时，就该更换主流候选设备。管理手段无法凭空造出缺失的应用、硬件、OEM 或固件能力。有一小类发现应当立即终止评估，而不是被当作条件继续带下去，因为再多的配置工作也改变不了它们。设备无法通过项目实际会使用的路径、从洁净状态被预配进预期的所有权模式——所有权在预配时即已决定，没有任何控制台设置能挽回这一点。某项必备控制在任何一层都没有实现机制：策略没有，应用没有，这一构建版本上的厂商框架也没有。候选设备只能通过一条无法再次交付相同 SKU 和构建版本的渠道获得，或者该渠道无法在目标市场开票和提供支持。区域变体缺少部署所需的频段、无线电核准或认证。没有任何已公布的更新或安全补丁信息覆盖预期的部署周期。或者两台设备在某项必备结果上存在无人能解释、也无人能控制的差异。尽早拒绝才是便宜的结局。第二台设备或第二名操作者可以发现一部分漂移。覆盖范围仍取决于渠道、构建和风险。本页不把两台或一周写成服务周期。当拒绝所指向的是任何主流产品都无法满足的需求，而不是这一款手机本身时，接下来要问的就完全是另一个问题了——究竟是配置过的标准设备、三防或专用产品，还是更深层的定制工作才是正确路径——这一比较在定制与现成 Android 设备对比中展开。

• 控制台里存在相应设置，但这一确切构建版本给不出所需的结果。
• 应用或外设在真实工作流程中失败，或无法从约定的重置状态恢复。
• 区域 SKU、渠道或第二台设备存在差异，且该差异改变了某项必备结果。
• 供货、维修、更新或更换方面的证据无法支撑所需的部署周期。
• 某项实质性缺口既没有责任方，也没有受支持的路径或可接受的限制。

把结论移交至部署验收

一份“接受”的设备适配结论只是授权进入下一验证阶段，它不等于批量批准。请保留候选设备身份、范围、结果、例外、责任方和证据链接，然后确定应用、策略、预配、市场、预配作业和批次验收基线。更完整的证据集见MDM 就绪与部署就绪 Android 设备对比，量产路径见Android 设备预配方式。向前传递的内容刻意收得很窄：固定了型号、SKU、构建版本、应用版本、策略版本和预配路径的受版本控制的样机；由控制测试和恢复演练产生的验收矩阵条目，每条都带判定和责任方；限制日志；以及已由第二个人证明可以照做的预配作业指导书。随后的批次预配是复现这一状态，而不是重新发明它——同一条路径、同一个策略版本、同一个应用构建版本，逐台与参考样机比对，并设置停止规则：一旦某台设备出现偏差就让产线停下来，而不是任由偏差变成新的常态。Vantora 的项目报价从 500 台左右起，而在项目内先行投放二十到一百台的试点批次，是在真实运行条件下——真实用户、真实站点、真实网络——确认评估结论的常见做法，之后再对其余设备做批次预配。本页所描述的评估，正是让这次试点值得一做的前提：没有它，试点会去发现设备问题；有了它，试点才能腾出手来发现只有规模化之后才会出现的工作流程问题。

申请设备适配评审

请提供确切型号或候选清单、采购渠道、目标国家、所有权模式、应用与 EMM 现状、必备控制项、数量区间、生命周期需求和验收优先级。初次评审不需要最终客户名称和涉密商务细节。如果已经在内部测试过某个候选设备，请把现有测试记录原样发来——包括那些没有做的检查项——因为最快的评审都是从一份诚实的不完整记录开始，而不是从一份总结开始。