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

简要答案

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

已安装不等于应用就绪

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

测试前记录基线

不要脱离具体内容批准所谓的“Android 版本”或“APK”。应为参考样机建立配置版本记录，至少记录具体设备型号和区域 SKU、Android 版本和固件配置版本、应用包及版本、签名来源、分发路径、管理模式、策略版本、外设、网络条件、目标市场和测试日期。当应用包含实时语音或视频功能时，还应按照 Android WebRTC 视频通话硬件指南，把通话配置和样机证据纳入这份基线。

如何在候选设备上测试配置版本

大多数检查清单只写明要验证什么，却把方法留给读者去意会，而评估恰恰在这里悄悄走偏：测试跑完了，也通过了，但它们能证明的东西比团队以为的要少。先从安装路径开始，因为它会改变随后每一项结果的含义。评估阶段，工程师通常会在开启 USB 调试的工作站上用 ADB 把配置版本推到设备上，这在快速迭代修复功能缺陷时是合理做法，但它并不是整个设备群会走的路径。由设备策略控制器（DPC）驱动的托管安装发生在无人在场时，可能在任何人登录之前就已完成，处于策略已经施加的限制之下，并且这次安装归属于受管渠道，而不是某个本地会话。真正让团队措手不及的是量产环境的限制集合：一条禁止从未知来源安装、或干脆阻止 USB 调试与应用安装的策略，会关掉评估所依赖的那条路径，于是在实验台设备上安装顺利的安装包，在量产设备上根本无路可走。在把应用视为“可安装”之前，先在候选设备上测试受管路径；侧载只留给调试迭代使用，并在事后重新测试。交付路径的整体框架见在 Android 设备上批量预装应用；这里的论点更窄——用来跑测试的那条路径，本身就是该测试结果的一部分。接下来，确认实际交付的是哪种架构。设备会报告主 ABI 和次 ABI，常见的是 arm64-v8a，并在平台仍提供的情况下支持 32 位；Android 的 ABI 文档说明了安装包中的原生库如何与设备匹配。ABI 不匹配导致的故障，很少看起来像 ABI 故障：要么因为没有匹配的原生代码而安装被拒绝，要么因为安装包恰好带有一个可用的库目录而安装成功，随后在首次调用扫码、相机管线或加密模块时，应用带着原生库加载错误崩溃。如果应用以 Android App Bundle 形式发布，测试人员侧载的通用 APK，与受管渠道针对那台具体设备生成的分包，并不是同一个构建产物，因此要记录测试的究竟是哪一个，并与设备群将实际收到的内容核对一致。版本边界同样需要照字面对待。清单文件中声明的最低和目标 API 级别，既决定资格也决定行为：Android 版本低于所声明最低值的候选设备，会被受管渠道直接过滤掉，而不是收到一条错误提示，因此症状表现为设备根本收不到应用分配；目标级别则决定哪些平台兼容性行为生效。Google 还对新上传的应用执行滚动更新的目标 API 级别要求，因此一个较旧的内部版本完全可以拿来测试，却仍然无法通过项目打算使用的渠道发布。然后，测试设备群会拿到的那个配置版本，而不是开发者手上打开的那个。调试版本与候选发布版本之间的差异，恰恰会掩盖真实故障：签名密钥不同、debuggable 标志被置位、代码压缩与混淆被削弱或跳过、保留了详细日志，以及——一个常在后期出现的意外——网络安全配置中的调试覆盖项处于生效状态，于是整个评估期间一直可用的内部证书或自签名证书，在正式签名的发布版本上不再工作。代码压缩本身还会带来一类缺陷，因为反射、序列化和依赖注入往往只有在启用混淆之后才会失效。签名身份的意义还不止于首次安装，因为更新能否被接受取决于它；应用签名所述的签名密钥保管归属，应当在样机验收之前而不是之后就确定下来。以上所有测试都要在实际将要采购的那个区域 SKU 上进行。同一个机型系列可能在多个型号编号上共用同一个市场名称，而这些型号在射频频段、内存档位、预装软件、固件分支、默认语言集，以及在部分市场上是否搭载 Google 服务等方面并不相同——从同事那里借来的外观相似的设备，是找缺陷的好工具，却是很差的验收对象。最后，每一次测试都要采集同样的字段，否则日后无法相互比较：设备机型与型号编号、构建指纹与安全补丁级别、应用包名及其版本名称与版本号、签名证书摘要、安装路径、当时生效的策略版本、测试人员与日期，以及原始材料——故障前后的日志片段、工作流程录屏，以及任何崩溃或 ANR 记录。正是这套字段，让一条测试结果得以成为验收矩阵中的一行，也让Android 批次预配能够复现受测条件，而不是近似模拟。

桌面测试掩盖了什么：后台执行与电源策略

在一台插着电、屏幕常亮的设备上做十分钟测试，几乎触及不到决定应用能否撑到一个班次结束的那些平台行为。Android 会主动限制空闲设备允许做的事：当设备拔离电源、静止且屏幕熄灭时，低电耗模式与应用待机会推迟后台工作、闹钟和网络访问，并在维护窗口内放行；应用待机分组则会降低不常用应用可以运行的频率。接在充电器上的设备永远不会进入这种状态，这正是桌面测试能通过的原因。因此评估方案必须主动制造这种状态——拔掉电源、锁屏、按真实班次时长放置；在工程迭代阶段则刻意把设备置入空闲状态和较低的待机分组，而不是等平台自己走到那一步。长时间运行的工作也需要一个平台真正认可的机制。前台服务对用户可见，并且在较新的 Android 版本上必须声明服务类型及其对应权限，还要在平台允许的条件下启动；可延后的工作应放进计划任务；精确闹钟则仅限于符合条件的应用类别使用。一个建立在普通后台线程加精确闹钟之上的应用，可能在实验台上安稳运行一周，随后在整个设备群上丢掉通宵同步。电池优化豁免是最常被想当然、而不是被验证的一环。豁免会改变平台对待应用的方式，但拿到豁免是一个策略问题，而不是应用里的一项设置：在非受管设备上，它要走一个对用户可见的提示流程；在全托管或专用设备上，EMM 可能可以直接下发——此外，OEM 自带的电源管理层还可以叠加在平台行为之上，按 Android 文档并未描述的规则终止应用。这些层取决于 OEM、机型和固件，必须在候选设备上实测确认，而不能从平台文档推断。这对部署有两点影响。第一，应用所依赖的任何豁免，都必须属于批次预配所应用的那一版策略；否则样机是靠测试人员手工设置的豁免通过的，而批次出货时并不带这项豁免——这正是“一台设备能用”与“一整批设备能用”之间最常见的落差。第二，这项依赖应连同重新验证触发条件一起写入已知限制库，因为一次固件更新就可能改变电源管理行为，而应用本身毫无变化。同样的道理适用于测试人员在样机上手工配置的其他一切：凡是没有写进记录在案的基线，在批次上就等于不存在。

• 电量充足且插着电——设备永远不会进入后台工作被推迟的空闲状态。
• 屏幕常亮且已解锁——没有锁屏、没有待机降级、没有维护窗口的时序问题。
• 开启了开发者选项和 USB 调试——而量产策略通常并不允许这种状态。
• 信号良好的 Wi-Fi、刚刷新的令牌和空的本地数据库——没有一项符合一个班次进行到第八小时时的真实情况。
• 在单台设备上手工设置的豁免与选项——除非由策略下发，否则批次上并不存在。

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

通用设备跑分回答不了这些问题。硬件选型应围绕应用要完成的任务，而不是围绕处理器或内存的宣传数字。

• 已定义主要用户、任务、使用环境和成功标准。
• 具备可供测试的代表性登录、租户、角色和账户恢复路径。
• 在相关情况下，覆盖在线、弱网、离线、同步和会话中断时的行为。
• 列明所需的相机、NFC、条码、打印机、扫描器、底座、蓝牙或 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、配件、标签、纸箱和异常记录。
• 质检将批次与参考样机逐项比对，并对实质性偏差设有停止规则。
• 激活、更换、质保、支持、升级处理和补单说明均已就绪。
• 接收团队清楚哪些操作仍需在现场完成，以及设备到货时本应已经处于什么状态。

在试点之前分配责任

以下是一个规划模型，而不是通用合同。每一行都应在实际项目的责任矩阵中确认。Vantora 的应用与 SaaS 公司合作伙伴页面介绍了相关交付范围。

只有在证据环环相扣时才放行批次

当确切基线已经记录、关键场景全部通过、有条件条目均有责任方、预配流程能够复现样机，并且支持与变更控制规则切实可用时，设备才算为约定批次做好了准备。一旦某项实质性变更让这些证据失效，就绪状态也随之失效。正是这条更宽的证据边界，使MDM 就绪与部署就绪 Android 设备对比成为必要的区分——注册可以是必要条件，却不是充分条件。把硬件、应用、策略、验证和交付各层串联起来，正是 Android 设备部署集成商的协调工作。真正实用的问题是：这个确切的应用、设备、管理路径和作业流程，能否在目标条件下被验收，并可重复复现？