Android 设备可行性评估：采购前的 20 个问题
在确定设备路线之前，先确认某一具体设备、构建版本、应用、管理路径、市场与交付计划的组合能否满足真实的工作流程；哪些环节尚未得到验证；以及受版本控制的样机必须证明什么。诚实的结论只有三种：进入样机验证、重新界定范围并补齐证据缺口，或停止所提议的路线。
- 作者
- Vantora
- 发布于
- 更新于
可行性评估是一道决策关卡，而非量产批准
可行性评估将一条拟议的 Android 设备路线转化为一个有边界的决策。它应当明确具体的候选基线、仍然缺失的证据、掌握这些证据的责任方，以及必须接受测试的受版本控制的样机。它不会把一条产品目录中的宣称、一次成功的注册或一份意向性报价变成量产批准。
| 结论 | 含义 | 下一步行动 |
|---|---|---|
| 进入样机验证 | 候选基线与样机计划已足够明确，但计划中的样机测试尚未通过。 | 构建或采购已记录在案的样机，并执行商定的验收场景。 |
| 重新界定范围并补齐缺口 | 仍存在一条可行的路线，但需求、证据、责任归属或商务条件必须调整。 | 明确未决条件、其责任方、其后果，以及再次决策所需的证据。 |
| 停止该路线 | 在当前范围内，某项关键约束没有可接受的解决方案。 | 避免做出采购承诺，并比较其他设备、平台、市场或交付路径。 |
报价之前的六条证据边界
平台文档和结构化的需求收集都很有价值，但它们各自能证明的内容都比项目承诺窄得多。应利用这些边界来判断采购方还需索取或测试什么。
| 已核实的事实 | 能够证明什么 | 无法证明什么 | 采购方行动 |
|---|---|---|---|
| Android 设备需求清单将工作流程、硬件、市场、应用、管理、数量与验收等输入项分别列出。 | 一份有用的项目简报，仅有机型和数量是不够的。 | 所要求的组合是可行的。 | 用证据、责任方和后果闭合每一项关键输入。 |
| Google Play services 客户端库在运行时与已安装的 Google Play services 应用中的服务进行通信。 | 应用可能存在超出“Android”一词范畴的平台服务依赖。 | 特定生产环境应用需要哪些服务，以及这些服务缺失、被停用、版本过旧或离线时应用会如何表现。 | 梳理生产环境安装包的依赖清单，并测试相关服务状态。 |
| Android 的受管配置模型要求应用声明其支持的选项，并读取和应用所接收到的值。 | 应用与 EMM 的责任是相互耦合的。 | EMM 控制台能够创造出应用未曾实现的行为。 | 核实配置架构（schema）、下发的值、应用的响应及错误反馈。 |
| 对于 Android Management API 部署，注册令牌与配置方式决定了设备所有权和管理模式。 | 在该 API 路径下，设置状态是一项架构输入。 | 每个 EMM 或每个具体构建版本都支持同一路径。 | 先选定目标状态，再在所选平台上测试干净状态下的设置与恢复。 |
| 满足 CDD 要求并通过 CTS 测试即可使设备具备 Android 兼容性；制造商随后才可以考虑 GMS 授权。通过 Play Protect 认证的设备已通过兼容性测试，并依授权预装了 Google 专有应用。 | 兼容性与 Google 授权是两类不同的证据。 | 市场核准、生命周期条款、EMM 支持或客户工作流程验收。 | 记录具体 SKU 与软件状态证据，然后分别验证其他权责方的事项。 |
| 经脱敏处理的项目简报可以省略最终客户名称及不必要的商务细节。 | 初次评估即可保护身份信息与敏感数据。 | 工作流程、国家/地区、数量范围、依赖项或硬性约束也可以省略。 | 删除凭据、密钥及无关的身份数据，同时保留对决策至关重要的事实。 |
一次有用的评估应产出什么
产出应当简短、具体且可测试。它是针对候选路线的决策记录，而非一份泛泛的设备推荐。
| 评估产出 | 应包含的内容 | 重要性 |
|---|---|---|
| 具体候选基线 | 机型、区域 SKU、相关时的硬件修订版本、Android 与固件构建版本、应用版本、管理状态、配件及市场。 | 防止将产品系列层面的宣称当作已通过验收的设备。 |
| 证据缺口与责任方映射 | 哪些已确认、哪些是假设、哪些仍待补齐；由谁提供；以及各自支撑哪项决策。 | 在第三方依赖演变为批次异常之前使其清晰可见。 |
| 受版本控制的样机计划 | 待构建的基线、关键场景、通过标准、证据格式、测试责任方及验收决策方。 | 将“请寄一台样机”变成一个受控的验证步骤。 |
| 停止与重新界定范围的条件 | 缺少责任方、控制能力不可用、市场不匹配、生命周期缺口、商务约束或关键场景测试失败。 | 防止惯性或沉没成本取代可行性决策。 |
关卡 1：工作流程与运行条件
从设备的实际使用方式入手。技术规格只有在能映射到用户的运行条件和可观察的结果时才有用。
| 问题 | 证据与采购方行动 |
|---|---|
| 1. 设备必须完成什么具体任务？什么才算成功？ | 记录从开机到完成目标结果的完整流程、关键步骤、明确的时间或精度阈值、失败状态，以及判定工作流程是否通过的一方。“能运行我们的应用”不是一个可测试的结果。 |
| 2. 每台设备归谁所有、由谁使用？ | 明确终端设备是归属单个员工、跨班次轮换使用、兼顾个人与工作混合使用，还是承担专用功能。答案不同，身份、重置、支持及管理状态方面的需求也随之不同。 |
| 3. 设备必须在什么环境下工作？ | 定义室内或室外使用、温度、防尘防水、跌落或振动、戴手套操作、光照、噪声、Wi-Fi 与蜂窝网络条件、离线时长、充电条件及班次时长。将每一项关键条件转化为样机测试场景或明示的限制。 |
| 4. 哪些外设和物理接口是必需的？ | 列出扫描器、摄像头、NFC、传感器、端口、按键、打印机、底座、支架、充电器、SIM 卡及配件。要求提供针对具体连接方式和工作流程的证据——而不仅仅是规格书上的某个端口或射频模块。 |
关卡 2：应用与平台
应用及其平台依赖必须冻结到可供测试的程度。演示版 APK、测试租户与生产版本并不是可以互换的基线。
| 问题 | 证据与采购方行动 |
|---|---|
| 5. 将评估哪个具体的应用构建版本？ | 记录包名、版本、签名责任方、发布状态、分发渠道、测试访问权限、后端环境及已知限制。 |
| 6. 工作流程需要哪些平台服务和 Android 行为？ | 检查 Android/API 级别、Play services、WebView、身份认证、权限、后台任务、通知、原生库、硬件 API 及离线行为。如果 Google 应用至关重要，应在一台运行目标制造商签名软件的代表性设备上核实 Play Protect 认证，并留存 SKU 与软件状态证据。 |
| 7. 应用将如何安装、配置、更新和恢复？ | 在受管分发、商定的预装或受控预配之间做出选择，然后从所要求的干净状态开始测试该路径。定义更新审批、签名的连续性、更新失败后的恢复、重置行为及离线处理。 |
| 8. 每项需求由哪个控制层负责？ | 将每项控制分别映射到应用或启动器、EMM/MDM、Android Enterprise、OEM 功能、固件或运营流程。平台路径的比较可另行参考 GMS 与 AOSP 对比指南。 |
关卡 3：具体设备、市场与供应
可行的设备是特定市场和特定供应路径中的一个具体候选对象，而不是一个产品系列名称。在将报价视为承诺之前，先落实具体的商务与实物基线。
| 问题 | 证据与采购方行动 |
|---|---|
| 9. 具体的候选基线是什么？ | 确定机型、区域 SKU、软件构建版本、内存与存储配置、射频规格、相关时的硬件修订版本及平台状态。从实物样机和权威记录中采集证据。 |
| 10. 涉及哪些国家和网络？ | 列明国家/地区、运营商、所需频段、SIM 或 APN 假设、认证、标签、充电器、语言、进口商责任及行业专项审查的责任方。市场准入和运营商适配是具有时效性的、针对具体机型的问题。 |
| 11. 哪些数量、试点、日期和替代规则决定了这条路线？ | 采用切合实际的数量范围、试点规模、里程碑、复购周期以及可接受或禁止的替代方案。MOQ、NRE、价格和交货周期必须来自实际在用的供应商路径，而不是一篇泛泛的文章。 |
| 12. 供应与生命周期有哪些证据支撑？ | 索取供货情况、停售风险、公开发布的操作系统或安全更新条款、备件、保修、维修、更换及后继机型选项。经销商类别或目录并不构成供货、更新或首次开机方面的承诺。 |
关卡 4：管理、配置与数据
先确定所有权与管理状态，再选择策略或配置路径。所选定的 EMM、Android 版本、OEM 实现及具体设备仍须证明各项控制能力切实可用。
| 问题 | 证据与采购方行动 |
|---|---|
| 13. 需要什么样的所有权与管理状态？ | 确定该路线需要的是工作资料（work profile）、公司自有设备上的工作资料、完全受管设备还是专用设备。Android Enterprise 对这些管理集合有明确区分；应对所选 EMM 和设备实现进行验证，而不是假定每项控制都能原样迁移。 |
| 14. 设置必须从哪种干净状态开始——且能否重复执行？ | 定义起点是恢复出厂设置、经销商已注册、已预配还是更换设备。测试设置中断、网络前置条件、重置、重新注册及租户分配。结合 Android 设备配置方法确认最终选定的路径。 |
| 15. 哪些账户、数据和支持访问需要审批？ | 记录身份、数据流、日志、远程支持访问、留存、删除及退役处置，并指明各项的责任方。对安全、隐私、法务、客户 IT 及行业审查作出标记提示，而不是取代这些权责方。 |
| 需要保持可见的管理边界 | 策略控制台或注册记录并不能证明应用工作流程、市场路径、外设行为、恢复能力或批次一致性。这些测试应保留在样机计划中。 |
关卡 5：变更控制与交付
一旦构建版本、应用、策略、配件或现场设备发生变化，一个良好的候选方案仍可能失败。在项目依赖可重复的批次之前，先定义责任归属与证据。
| 问题 | 证据与采购方行动 |
|---|---|
| 16. 每一项重大变更由谁负责？ | 为应用、后端、签名、策略、受管配置、Android 或固件构建版本、OEM 功能、外设及市场要求分别指定责任方。定义哪些变更会触发重新验证，以及谁有权批准例外。 |
| 17. 设备在现场发生故障时怎么办？ | 规划诊断、恢复、更换或 RMA、重新注册、数据处理及退役处置。未记录在案的密码或不受控的手工步骤都是可行性缺口。 |
| 18. 整个批次中哪些内容必须保持一致或留有证据？ | 定义构建版本、应用与策略版本、标识符、配件套件、包装、预配记录、QA 抽检样机及例外规则。只有当已验收设备的基线能够指导可重复的移交时，这台设备才有意义。 |
关卡 6：样机计划与可行性结论
最后一道关卡并不会让量产批准自动生效。它要决定的是：证据是否足以定义并验证一台样机、路线是否必须调整，或者是否应当停止。
从脱敏简报到受版本控制的样机
一份有用的初始简报既能保护身份与敏感信息，又不会遗漏对决策至关重要的事实。它应保留工作流程、国家/地区、数量范围、应用与管理依赖项、硬性约束及验收目标。
- 1提交一份可用的脱敏简报，包含工作流程、应用状态、市场、数量范围、控制要求、外设及验收优先级。
- 2列明缺口与责任方；将事实、假设、第三方依赖和未决事项分开呈现。
- 3通过比较现成产品、成熟平台集成与更深度的定制，选择最轻量的可行路线。参见定制与现成 Android 设备对比。
- 4冻结拟议的样机基线：具体设备、构建版本、应用、策略、设置状态、配件及计划中的测试条件。
- 5执行证据关卡，并依据商定的标准和指定的决策方，批准样机验证、重新界定范围或停止。
在将答案视为已闭合之前先指定责任方
这是一套规划模型，而非一份通用合同。评估让权责边界变得可执行；它不会免除 OEM、EMM、运营商、认证、应用或客户各自的责任。
| 责任方 | 常见职责 | 需索取的证据或决策 |
|---|---|---|
| 客户或系统集成商 | 工作流程、环境、市场、用户模型、策略决策权、验收及发布决策。 | 经批准的脱敏需求、测试优先级及指定的验收决策方。 |
| 应用或 SaaS 团队 | 安装包、签名、后端、身份认证、配置架构（schema）、版本发布及应用支持。 | 版本记录、测试访问权限、依赖清单及应用的已知限制。 |
| EMM、OEM、运营商或其他提供商 | 由该平台或供应商控制的能力与服务。 | 现行的机型/SKU 支持证据、配置记录、承诺及未解决的依赖项。 |
| Vantora 设备项目团队 | 需求发现、候选方案协调、设备配置规范、样机基线、验收证据、预配计划及移交协调。 | 可行性说明、证据缺口映射、构建记录、样机计划及批次控制。 |
让证据边界始终清晰可见
这六道关卡是 Vantora 的决策框架，而非 Android 认证或性能测试结果。可行性结论为正面时，它定义的是样机必须证明什么；它并不能证明量产就绪、市场核准、供应商供货、确切交货周期或未来的更新行为。
- 产品系列、目录收录或经销商类别，都不能作为具体 SKU、固件构建版本、供货情况或目标市场的证据。
- Android 兼容性并不自动等同于 GMS 授权、运营商核准、生命周期保障、EMM 支持或客户工作流程验收。
- 管理策略无法创造出应用尚未实现并测试过的应用行为。
- 受版本控制的样机结果仅适用于其记录在案的设备、构建版本、应用、策略、环境和场景，直至重大变更触发重新验证。
- 项目验证不能取代由相应权责方负责的认证、隐私、法务、进口商、运营商或行业专项审查。
官方来源核查日期：2026 年七月 23 日
以下链接用于说明平台机制与边界。它们不能替代针对具体设备、构建版本、EMM、应用、市场或供应路径的项目专属证据。
提交经脱敏处理的项目简报
如果工作流程真实存在，但机型、平台、管理路径或样机计划仍不明确，请提交经脱敏处理的项目简报。初步评估不需要最终客户名称、凭据、签名密钥及无关的商务细节；但需要那些左右决策的事实。
常见问题
Android 设备可行性评估等同于报价吗？
不等同。报价是对已定义的路线和范围进行定价。可行性评估判断的是该路线是否已足够明确、还缺少哪些证据，以及样机必须证明什么。
完成评估就等于批准量产批次吗？
不等于。正面的评估结果定义的是样机与验证路径。量产放行仍需要商定的证据、已闭合或已接受的条件、可复现的批次预配以及指定审批方的批准。
为什么在样机之前就必须明确具体 SKU？
同一产品系列可能包含不同的射频规格、内存配置、软件构建版本、生命周期条款、配件及区域核准。样机应与实际的候选基线绑定，而不是与产品系列层面的描述绑定。
初始简报可以做脱敏处理吗？
可以。最终客户名称、凭据、密钥及无关的商务细节可以不出现在初次评估中。但应保留工作流程、国家/地区、数量范围、应用、管理依赖项、硬性约束及验收优先级。
当某项控制依赖 OEM、EMM 或应用提供商时，答案由谁负责？
控制相关产品、租户、软件或服务的一方必须提供其证据或承诺。可行性评估会记录该责任方、缺口及后果；它不会将其他方的权责转移给 Vantora。