面向 SaaS 与软件团队的应用就绪 Android 设备检查清单

简要答案

本检查清单帮助 SaaS 和软件团队在确定批量订单前，判断应用就绪设备所需证据是否确实存在。本指南中的“应用就绪”是 Vantora 的项目术语，并非 Google 或 Android 认证。项目团队必须把 Android 各自独立的兼容性、权限、分发、管理和更新机制，整合到一个具体配置版本上的真实工作流程中。

已安装不等于应用就绪

安装测试只能证明应用包能够通过受测路径送达受测设备，不能证明完整的实际使用流程。Android 根据具体平台版本定义应用兼容性，并指出平台变更可能影响应用，因此必须验证目标 Android 版本和固件配置版本；参见 Android 的应用兼容性指南。

测试前记录基线

不要脱离具体内容批准所谓的“Android 版本”或“APK”。应为参考样机建立配置版本记录，至少记录具体设备型号和区域 SKU、Android 版本和固件配置版本、应用包及版本、签名来源、分发路径、管理模式、策略版本、外设、网络条件、目标市场和测试日期。

1. 检查真实应用工作流程

通用设备基准测试无法回答这些问题。硬件选择应围绕应用所执行的任务，而不是宣传页上的处理器或内存参数。

• 已明确主要用户、任务、环境和成功结果。
• 可测试具有代表性的登录、租户、角色和账户恢复路径。
• 适用时，测试范围涵盖在线、弱网、离线、同步和会话中断行为。
• 已列出所需的摄像头、NFC、条码、打印机、扫描器、底座、Bluetooth 或 USB 交互。
• 已记录后端、证书、VPN、域名、时间、位置或 API 相关条件。

2. 检查具体硬件与市场版本

这些是可行性评估的输入条件，而不是普遍适用的产品声明。在确定采购数量前，应依据需求比较主流设备、三防设备或深度 OEM 路线。

• 屏幕、内存、存储、CPU 架构、摄像头、传感器和端口适合工作流程。
• 电池、充电、配件、安装方式和环境条件能够满足实际作业班次。
• 已记录具体区域 SKU，而不只是型号系列。
• 蜂窝频段、运营商适配、认证、进口商义务和目标国家相关条件均已指定责任方。
• 型号供应情况、替换路径和预期生命周期符合项目需要。

3. 检查应用交付与版本标识

应有意识地选择交付路径：托管 Google Play、约定的预装，或受控的 APK 预配。三者不能互换。Google 文档说明，托管 Google Play 可以通过设备策略安装应用，还能把私有应用限制在一家企业内；参见托管应用分发文档。这对受支持的托管部署很有用，但并不意味着每个 AOSP、非 GMS、OEM 或非托管配置版本都能采用同一路径。

• 已记录应用包名称、版本代码、发布渠道和签名责任方。
• 所选路径能够从预期的设备洁净状态完成应用交付。
• 使用托管 Google Play 时，私有应用的可见性和租户分配均正确。
• 针对安装失败、下载中断和重新安装行为，已有明确的支持路径。
• 量产批次将使用同一个获批准的应用包和交付路径。

4. 检查首次运行、权限和配置

应用可能顺利安装，却在第一次权限提示时失败。在受支持的现代 Android 版本中，危险权限必须在运行时请求，而且应用必须妥善处理用户拒绝授权的情况，不能假定已经获得访问权限。应按照 Android 的运行时权限流程，测试实际提示顺序、理由说明、授权、拒绝和恢复行为。对于远程配置，应确认应用提供并使用所需字段。Android 的托管配置指南明确由应用负责定义配置架构，EMM 无法凭空创建不受支持的字段。

• 首次启动无需执行未记录的手动步骤，即可进入预期界面。
• 在适当场景中请求所需权限，权限被拒绝时应用能够安全处理。
• 账户、租户、语言、区域、证书和端点配置均正确。
• 已测试重启、重新启动应用、退出登录、令牌过期和约定的重置场景。
• 配置版本中未嵌入生产环境凭据、签名密钥或不必要的客户数据。

5. 检查管理、Kiosk 与用户边界

首先确定设备采用哪种模式：个人自有、公司自有且可混合使用、全托管，还是专用设备。在 Android Management API 中，注册令牌和预配方式会确立所有权与管理模式；参见 Google 的预配文档。其他 EMM 架构可能不同，因此应验证所选平台，而不是照搬示例策略。Google 的专用设备策略示例可以在开机时自动启动指定 Kiosk 应用；这只是一种实现示例，并不代表普遍适用的控制承诺。

• 可以从预期的恢复出厂设置或洁净状态重复完成注册。
• 应用分配、策略、限制、网络设置和报告均下发到正确的租户与组。
• 单应用、多应用、定制启动器、白名单和支持访问要求均已明确。
• 已测试重启、锁定、解锁、重置、策略刷新，以及不可接受的退出或绕过路径。
• 支持团队已有恢复路径，不依赖未知密码或隐藏的设置步骤。

6. 检查更新、恢复与变更控制

首个版本只是设备项目的起点。只有满足身份和签名条件时，Android 才会接受应用更新：应用 ID 必须一致；签名证书必须一致，或使用有效的密钥轮换证明；还必须满足版本条件。在变更分发渠道或签名保管方前，请查阅 Android 的应用更新规则。Google 的 Android Management API 更新指南说明了托管应用在特定条件下可采用的默认、高优先级和延后模式；这些模式无法控制 OEM 固件发布。

• 应用发布责任、签名保管、批准和部署时间均有记录。
• 已了解所选渠道的常规、紧急和分阶段发布行为。
• 在影响重大的情况下，已测试更新失败、更新中断、数据迁移和恢复场景。
• 固件、应用、后端、策略和外设变更均设有重新验证触发条件。
• 除非具体渠道和应用数据模型支持经过测试的恢复路径，否则不能承诺“回滚”。

7. 检查样机验收

把每项关键期望转化为通过标准、测试方法、观察结果、证据引用、责任方和处置结论。只有明确定义含义后，才能使用“通过”“有条件”“失败”或“不适用”。样机验收矩阵提供了实用结构，但应由项目指定的决策方而不是模板来判定哪些条件足以批准发布。

• 已验收样机具有实物标识，并与其配置版本记录绑定。
• 关键用户流程已在具体样机配置上通过测试。
• 有条件项应注明依赖关系、影响、责任方、关闭条件，以及是否可以继续开展批次工作。
• 关键项目一旦失败，必须阻止发布，直到指定决策方批准新的处理路径。
• 适用时，应使用截图、日志、录像、控制台记录或检查说明来支持重要结果。

8. 检查批次预配与移交

预配把已验收样机转化为受控批次，而移交将决定接收团队能否真正投入运营。

• 量产设备按照已验收的应用、固件、策略和设置基线完成准备。
• 适用时，记录序列号、IMEI、资产、站点、租户、SIM/APN、配件、标贴、外箱和例外情况。
• QA 将批次与参考样机进行对比，并针对重大偏差设定中止规则。
• 激活、换机、保修、支持、升级处理和再次订购说明均已准备就绪。
• 接收团队清楚哪些操作仍须在现场完成，以及设备到货时应已处于什么状态。

试点前明确责任

以下内容是规划模型，并非通用合同。实际项目必须确认责任矩阵中的每一行。Vantora 的应用与 SaaS 合作伙伴页面说明了相关交付范围。

只有证据链完整后才批准批次

当具体基线已有记录、关键场景已经通过、有条件项已明确责任方、预配流程能够复现样机，并且支持与变更控制规则切实可用时，设备才达到约定批次的就绪条件。如果重大变更使这些证据失效，就绪状态也随之失效。正因为证据边界更广，MDM 就绪并不等于部署就绪；注册可能是必要条件，却不是充分条件。衔接硬件、应用、策略、验证和交付层，是 Android 设备部署集成商承担的协调工作。实际要问的是：在目标条件下，这个具体应用、设备、管理路径和运营流程能否通过验收并重复执行？