Android 设备配置规范应包含哪些内容？

简要答案

Android 设备配置规范是一份受版本控制的项目记录，写明一个批次预期复现的确切设备状态：哪一款实体设备、哪一个固件版本、哪些应用版本、哪套策略、哪条预配路径、哪些市场条件、哪些配件和包装——以及其中任何一项发生变动时，各由谁对这项决定负责。它在可行性阶段以草稿形式写就，在配置样机之前收紧为样机候选修订版本，并在样机通过评审和批准之后冻结为已验收的量产参考。有两点让它成为真正有用的文件，而不是装饰性文档。其一，每一个实质性字段都带有已批准取值、证据引用、具名责任方和变更规则，因此没有人需要去猜某个取值究竟是决定下来的，还是随手填上的。其二，它与一台受版本控制的样机配对使用：规范说明状态应该是什么，样机记录说明一台真实设备被实测为什么状态，而验收就是宣告两者在既定范围内一致的那一刻。Vantora 报价的项目规模从 500 台左右起，这类项目正依赖于这种配对关系，因为只有先有一个可供对齐的参考，量产一致性才谈得上有意义。

配置规范是一份受控的项目记录

Android 设备配置规范不是消费级参数表，不是 Android 应用的构建文件，也不是设备通过验收的证明。它是一份受版本控制的项目记录，用于定义预期的交付状态。“Android 设备配置规范”是 Vantora 的项目用语，而非 Android 官方的文档类型，因此每一个实质性字段都应当标识一种状态、链接到证据、指明责任方，并定义该状态变化时会发生什么。这种严谨并非人为发明，而是平台本身逼出来的：采购方视为同一件事的取值，几乎每一个其实都由若干项组成。Android 把机型、产品、硬件、SKU 和构建版本标识作为彼此独立的字段暴露出来；版本名称、API 级别、构建版本标识和安全补丁级别各自独立变动；一个应用带有包名、版本号（version code）、版本名称（version name）和签名标识，这些都不可互相替代。任何把上述内容压缩成一句友好措辞的规范，都已经失去了判断两台设备是否相同的能力——而这恰恰是批次检查唯一真正能回答的问题。同样重要的还有一个推论：兼容性结论、授权许可、市场准入和验收证据应各自保留为独立记录、各有其持有方，因为一份把它们全部吸收进来的规范，会变成人人引用、却无人能核实的文件。

什么是受版本控制的 Android 设备样机

配置规范描述的是意图。受版本控制的样机则是它的实物对应物：一台已完成配置的设备，其完整身份已被采集、写入记录并纳入变更控制，因此日后关于整批设备的任何声明，都能追溯到某个在已知日期确实摆在测试台上的实物。这个说法之所以重要，是因为“我们寄出去的那台样机”并不构成记录。它指的是一个物件，而不是一种状态。三个月后，没有人能有把握说清那台设备当时装的是哪个固件版本、安装的应用版本号是多少、启动器在演示与批准之间有没有升级过，或者测试人员跑 Kiosk 场景时应用的是哪一版策略。受版本控制的样机能凭书面记录而不是凭记忆回答上述全部问题，之所以做得到，是因为身份是在配置当时采集的，而不是事后回溯拼凑的。样机所携带的身份分三层，每一层的存在都有不同的理由。采购身份——制造商、具体机型、区域 SKU、内存与存储规格、供货渠道——回答的是“这台设备日后还能不能在目标市场再买到？”，而这恰恰是一台看似理想的样机在几个月后最常失守的地方。运行时身份——序列号、IMEI、Android 版本与 API 级别、安全补丁级别、固件构建版本 ID 或指纹、GMS 或 AOSP 状态——回答的是“量产设备是否真的是同一套软件平台？”；它取自设备本身而不是参数表，因为两者不一致的频率远高于采购方的预期。配置身份——应用包名连同版本号和版本名称、签名与分发路径、启动器包名与版本、DPC 或管理代理版本、策略配置修订版本、所有权模式与预配路径——回答的是“这台设备上究竟应用了什么？”。在这三层之上还有一组流程字段，它们让记录站得住脚，而不只是详尽：配置日期、具名测试人员、该设备所对照的验收矩阵修订版本、随之一并接受的已知限制，以及客户批准日期和批准人。缺了最后这一组，记录只是一份技术快照；有了它，记录才是一项决定。版本控制还带来快照所不具备的三项性质。历史状态被保留而不是被覆盖，因此关于某台在三月交付的设备的疑问，可以对照当时生效的修订版本来回答。每个修订版本都有其适用范围，写明它管辖哪些批次或分批，正因如此，一个二十到一百台的试点批次可以按某一修订版本执行，而项目其余设备则等待下一版。并且每一次变更都可归属——由谁提出、由谁批准，两者都有记录——这正是“修订”与“争论”之间的区别。把已批准状态复现到量产设备上的具体做法，属于 Android 批次预配的范畴；这里要说明的是，批次预配有一份固定的参考可供复现，并且当某台设备偏离该参考时，会有停止规则触发。

样机记录与配置规范如何互相引用

这两份记录回答不同的问题，不应相互重复。配置规范是规定性的：它写明每一个实质性字段的目标取值、围绕该取值允许的公差或变动范围、责任方和变更规则。样机记录是描述性的：它写明某一台真实设备在某个日期被具名人员实测为何种状态。验收就是把两者对照、并宣告其在既定范围内一致的那一刻；而这种对照之所以可行，正是因为两份记录使用相同的字段名称、相同的排列顺序。两者之间的关联应当明确而狭窄。配置规范载明它所对照验收的样机编号和样机记录修订版本；样机记录载明它所依据配置的规范修订版本，以及它所对照测试的验收矩阵修订版本。除此之外不复制任何内容。一个取值一旦在两份文件中重复出现，迟早会只在其中一份被更新，项目于是有了两个真相，却无从判断已出货批次究竟由哪一个管辖。若某个取值确实必须同时出现在两处——固件构建版本 ID 是最常见的情形——则由其中一份文件拥有它、另一份引用它，并在引用处写明哪一份具有权威性。遗留差距则另有归处：被接受而非被修复的限制，应连同责任方和重新验证触发条件一起进入已知限制库，而不是作为附注埋在某个规范字段里，因为一个读起来像是已批准的字段，下游所有人都会当作已批准来对待。

采用七个板块和四项字段控制

对每一个实质性字段，都要记录已批准取值或有界范围、证据引用、确认责任方，以及变动或变更规则。尚未确定的字段应保持开放状态，并附上责任方和决策时点；不应用一个看似合理的猜测把它填满。正是这四项控制把规范与愿望清单区分开来，而应用这四项控制往往比字段取值本身更能说明问题——没有人愿意认领的字段，就是还没有人做过决定的字段。记录的结构应当让评审人一遍看下来就能判断：实体设备、软件平台、应用状态、管理设计、市场与配套、证据链条，是否都已由有权拍板的人拍板。多数规范略去的是边界——即写明每个板块刻意不涵盖什么——而正是这一遗漏，让认证结论和商务条款一步步渗进交付基线。机密内容则要完全排除在外：注册令牌、管理员凭据和签名材料只按存放位置和保管人引用，绝不粘贴进一份将作为附件流转的记录。

用受控条款取代含糊标签

目标不是把话写得更多，而是让解读变得更少。规范还是草稿时可以使用占位说明，但不能让一份已验收的量产参考，把实质性的未知项藏在“待定”、一张没有标注的截图或一个打不开的链接背后。含糊标签与够格写入规范的条款之间，区别是一致的：标签说的是结果，条款说的是取值、机制、责任方和允许的变动范围。“最新固件”是最清楚的例子，因为它根本不是一种状态——它是一个移动的目标，每台设备在预配当天各自解析出不同结果，而同一订单的两个分批最终落在不同构建版本上，正是这么来的。“与已验收样机一致”则是最危险的一句，因为它听上去像是最强的承诺，实际上却把全部定义都委托给了一份未必受版本控制的记录。上述每一项都还有一部分证据本就该放在别处，把它们硬拉进规范，正是一份交付基线沦为无人能评审、也无人信任到愿意去更新的文件的原因。

让各类部署记录彼此独立

配置规范定义目标状态。相邻的记录则分别定义需求、证明和逐台执行情况。让它们彼此独立，既保住了可追溯性，也避免某一份文件假装能回答部署中的所有问题。实用的判别方法是问：某项分歧应当对照哪一份记录来裁定。如果争的是某项要求当初是否达成一致，那是需求简报。如果争的是交付状态本该是什么，那是配置规范。如果争的是该状态是否被证明可行，那是样机验收矩阵，其中载有场景、预期行为、实测行为、结论和责任方。如果争的是哪些设备接收了哪种状态，那是批次预配或批次记录。把其中任意两者合并，就会得到一份两个问题都答不利落的文件：带着测试结果的规范，在任一场景被重跑的那一刻就已过时；而载入字段定义的验收矩阵，会变成大家去查量产取值、却从来没人在那里维护这些取值的地方。这种分离还决定了谁有权改动什么——其中最值得明说的一条规则是：批次预配记录永远不构成对已批准状态的变更授权。它只记录该状态已被应用，或者某台设备发生偏离并已被拦下。

先冻结参考，再控制变更

设备 SKU、硬件修订版本、固件指纹、补丁基线、应用构建产物、签名路径、策略、预配路径、市场条件、配件、品牌资产或包装，其中任何一项变化都可能改变这个配置。应开启一个受控的修订版本，与当前参考逐项比对，识别受影响的证据和验收条目，指定责任方，并在新状态被使用之前取得所需的决定。下面四种状态值得在文件本身上明确标注，因为设备项目中的多数混乱，都来自有人把一份草稿当成批准来读。草稿是欢迎质疑的；样机候选修订版本是一项承诺——承诺按某种特定方式配置一台设备；已验收的量产参考是一项带有范围和日期的授权；已被取代的修订版本是保留下来的证据，而不是应当删除的错误。这些检查点在更大的流程序列——可行性、样机、验收、批次预配、移交——中的位置，参见经验证的 Android 设备部署如何运作。

1. 1可行性草稿：已确认的要求、候选方案、未知项和责任方，且不含任何验收意味。
2. 2样机候选修订版本：样机意在代表的确切配置。
3. 3已验收的量产参考：在既定范围内经授权的样机决定、限制及证据。
4. 4已被取代的修订版本：在更新的已批准修订版本生效后仍予保留。

修订还是勘误：每种变更触发什么

参考一旦被验收，此后每一项变更提议都需要一条路径，而路径只有三条。勘误是在不改变设备状态的前提下更正文件——更正责任方姓名、澄清某项公差、修好一个失效链接。它会被记录、注明日期和责任人，但不触及验收，也不需要批准人重新查看设备。修订则改变预期状态，这意味着要有新的修订版本号、与上一版参考的差异对比、对哪些验收条目受影响的评估，以及在任何设备按新状态预配之前，由文件中具名的批准人作出决定。替代料或所有权模式变更属于第三种情形：它产生的是一台新样机，而不是一个修订版本，因为被验证的对象已经不再是当初被验证的那个东西。分界线不在变更的大小，而在原有证据是否仍然适用。一处外观性的包装内附页可以走勘误；换充电器则不行，因为电气与市场准入证据是附着在料号上的。从全托管改为专用的锁定配置属于修订，因为专用用法是全托管模式的子集，且该变更是以策略形式应用在一台已完成预配的设备上。而从工作资料改为设备所有者管理则根本不是修订，因为所有权在预配时就已固定，无法从控制台切换；设备必须从干净状态重新预配，并重新配置和验收一台新样机。这种不对称，是在把某种模式写进采购规范之前最值得先弄清楚的一件事，各模式之间的对比见专用设备与全托管 Android 设备对比。审批权限应当写进规范，而不是默认存在。多数项目中，技术责任方评估影响，客户批准人授权任何改变已验收行为或成本的事项，批次预配则在授权到位前保持暂停。之所以要点名这些角色，是因为代价高昂的失败并不是一个错误的决定，而是一项变更进入了量产，却没有任何人明确负责说“不”。

验收之后 OEM 发布新固件构建版本时怎么办

这是一台已验收样机悄然不再代表整批设备的最常见方式，值得为它写下明确规则，而不是临场应付。配置规范可以冻结它所记录的取值，却冻结不了制造商或运营商发布什么。验收之后数周才采购的设备，出厂时可能已经带着更新的构建版本；而一台到达现场的设备，如果更新路径不受控制，还会自行升级。Android 提供了系统更新策略，在 OEM 支持的前提下，作为设备所有者的设备策略控制器可以用它推迟安装或设定安装窗口，这一点值得启用——但它管的是受管设备上的安装时机，而不是到货批次预装的是什么，其行为也取决于 OEM 和平台。可行的应对分为四个部分。发现：在批次预配阶段把到货设备与记录在案的构建版本 ID 或指纹逐台比对，让差异在测试台上被发现，而不是在客户现场。分类：同一固件分支内的补丁级别变动，通常比一个新的构建版本 ID 影响面更窄，而一份明确写出补丁范围的规范，可以避免每月安全公告都要重开参考。界定重测范围：不必重跑整个矩阵，只重跑那些确实依赖平台的验收条目——从干净状态开始的注册、策略下发、锁定任务模式行为、外设驱动，以及应用的首次运行和权限路径。决定并记录：新的构建版本要么成为已验收参考的一个修订版本，要么把受影响的设备扣下并把差异上报升级。无论结果如何，结论都要写回配置规范；若某项差异是被接受而非被修复，还要连同责任方一起写入已知限制记录。要着力防范的失效模式是无声的那一种——设备带着无人比对过的构建版本出货，直到设备群中有一部分表现异常才被发现，而当时已无任何记录说明改动了什么。上述规则是规范侧的答案：参考说了什么、由什么权限来改动它。测试台侧的答案——到货批次究竟如何检查、重复订单上的小型试点复验是什么样子，以及不一致的设备如何被拦在放行流之外——属于 Android 设备批次预配。

替代申请如何评估

替代申请出现的理由都很寻常：某个版本停产、某个内存档位供货紧张、某款配件停售、某项交期滑出了交付窗口。这些理由是正当的，一概拒绝也算不上什么政策——但仅凭一份相似的参数表就接受某项替代，正是项目染上一个说不清来由的缺陷的方式。有效的评估按固定顺序进行。第一，弄清真正不同的是什么：不是市场型号名称，而是规范所管控的那些字段——SKU、射频与频段支持、内存与存储、固件分支、GMS 或 AOSP 状态、外设或配件料号、市场准入。第二，把每一处差异映射到验收矩阵上，标出它可能触及的条目；如果某处差异一条也触及不到，那多半说明规范漏管了某些本该管的内容。第三，按上文的规则确定路径：不同的区域 SKU 或硬件修订版本需要新样机，配件更换通常走修订，并写明已批准料号和替代规则。第四，如实估算评估成本，时间与金钱同样要算，因为在项目后期才出现的替代方案，会直接与它本要保住的交付日期相竞争。第五，把决定记录下来——包括拒绝的决定——以免同一申请在没有新信息的情况下卷土重来。有两条护栏值得预先写进规范。写明哪些字段本身就允许替代，让采购在提出之前就心里有数；并写明任何替代版本都必须经由与原方案相同的样机与验收路径进入项目，通常先在一个小批次上确认，再对项目其余设备进行批次预配。正是这种事先约定，让一次替代停留在排期问题的层面，而不至于演变成一场重新谈判。

下载设备配置规范模板

用这份模板记录预期的设备平台、软件与应用状态、策略、包装、配件、证据及批次预配引用。机密与商务条款请保留在各自的受控系统中，并把最终修订版本与支撑它的样机和验收证据关联起来。如果项目已经有一份其他格式的规范，有用的做法不是把它重写一遍，而是拿四项字段控制去检验它：每一个实质性字段是否都带有已批准取值、证据引用、具名责任方和变更规则？通不过这项检验的字段，正是部署通常出问题的地方，而在规范还是草稿时修补它们的成本很低。如果更上位的就绪度问题仍未解决——即一台能顺利注册的设备是否真的可以进入批次——请先看 MDM 就绪与部署就绪 Android 设备对比，然后带上目标机型、应用、管理平台、市场和数量区间，以便依据真实约束来构建规范。