面向经验证受控部署的受限用途 Android 设备

简报：定义设备可以做什么、不可以做什么

受限用途项目首先要列出边界清单：批准哪些应用、是否允许任何浏览器访问、是否允许使用摄像头／USB／NFC／蓝牙、谁可以更改设置、应用和 OS 如何更新，以及恢复出厂设置后应有何表现。简报还应说明每项限制背后的原因——控制分心、防止损失、控制数据路径、社群规则或监管要求——因为原因决定项目实际需要多强的防绕过能力，继而决定适用哪一层机制。仅需要简化操作界面的设备可以使用启动器；必须让某项功能彻底不存在的设备，则需要更深层的路径。在承诺采购任何硬件前，Vantora 会把边界清单转化为功能矩阵草案和建议的机制映射。此阶段的简报可以保持脱敏：只需提供设备类别、数量区间、限制清单和管理假设，即可获得切合实际的可行性答复。

• 获准应用清单，以及用户是否可以看到清单以外的任何内容
• 浏览器策略：不存在、被阻止，或仅限指定目标
• 摄像头、USB 数据、蓝牙和 NFC 的外设策略
• 应用、OS 和管理代理本身的更新策略
• 恢复出厂设置、更换 SIM 和更新 OS 后的必要行为

选择限制层：启动器、管理策略或固件

大多数受限用途要求都能在不止一个层级实现；这些层级的差异在于控制深度、投入和变更速度，并不能简单排成优劣。启动器控制用户看到和能够到达的内容；管理策略——Android Enterprise 加 MDM 或自定义代理——控制操作系统强制执行的规则；OEM 配置与固件工作则控制设备上究竟存在哪些功能。较浅层级部署和变更更快；较深层级能经受更多重置与恢复场景，但会让项目绑定特定机型和更长交付周期。许多经验证的配置会组合多个层级：以策略控制为基线，上层配合启动器界面，再对必须彻底移除而非隐藏的功能采用一两项固件级移除。正确组合取决于 OEM、平台和管理技术栈，需要在实际机型的样机验证中确认，而不是根据规格表推断。

配置：组合应用白名单、启动器控制和设备管理

配置内容可以包括固定启动器、应用白名单、浏览器移除或控制、阻止侧载、设置限制、托管注册、Kiosk 或专用模式、APN 或 Wi-Fi 配置文件、应用预装和包装。配置规范会记录功能矩阵中每一条由哪个层级执行，因为两种在用户看来完全相同的配置，在重置、更新或注册丢失时可能表现截然不同。Vantora 将这种机制映射视为交付物的一部分：采购团队收到设备，IT 团队收到有文件记录的控制路径，审批方收到一份验收矩阵，其中每项限制均注明执行层。部分限制可通过 Android Enterprise 和 MDM 处理；其他限制需要 OEM 支持、自定义代理或固件路径。正确组合取决于 OEM、平台和管理技术栈，并会在批次预配前按机型验证。

验证：量产前测试绕过路径

在实际样机上依据商定的功能矩阵测试常见绕过路径之前，一台受限用途设备还不能称为经验证的配置版本。Vantora 会检查从设置和恢复模式执行恢复出厂设置、安全模式、应用侧载、USB 调试、强制门户行为、获准应用内的 WebView 界面、添加账户流程、通知和 Intent 绕出路径、OTA 行为，以及适用时的商店访问。每项检查都会记录观察结果和执行该限制的层级；若测试失败，要么在更深层修复，要么在批准批次前写入已知限制记录。产出不是笼统的安全承诺——负责任的供应商都不会给出这种承诺——而是针对所选设备路径的项目级验证记录，并提前披露限制，而不是等设备投入现场后才发现。下表显示单机型配置的典型验证范围。

• 分别从设置和恢复模式检查恢复出厂设置及恢复行为
• 依据矩阵检查侧载、应用商店和浏览器访问
• 审核启动器、设置和快捷设置限制
• 检查 MDM 注册持续性和策略更新路径
• 在批准批次前记录并披露已知限制

预配：准备受控设备群，而不是一批散装手机

批次预配可以包括应用预装、经验证的策略状态、资产标签、序列号或 IMEI 记录、包装分组、基于角色的配置文件，以及给接收团队的移交说明。预配也是逐台验证发生的环节：通过抽检或全检，确认每台设备离开产线时确实处于已验收状态，而不只是曾经向它推送过配置。对于多角色设备群——例如一个用户组采用无浏览器配置文件，另一个用户组采用受限 Web 配置文件——预配会按标签和包装箱将配置文件对应的设备物理分开，避免错误配置悄然发给错误群体。这样，受控用途要求就成为可重复的设备群配置，而不是交付后支持负担沉重的手动设置；IT 团队也能获得可核对的批次记录，而不是一堆无法识别的箱子。

部署：让控制措施始终关联已验收样机

已验收样机会记录所选机型、OS 或固件版本、策略路径、应用版本、重置行为和已知限制。后续批次依据同一验收矩阵进行核对，避免细微的平台变更悄然削弱控制模式——典型故障是 OS 或管理代理更新重新打开了无人复测的绕出路径。如果平台迫使项目变更，Vantora 会将其作为相对于验收矩阵的书面差异提出，让项目只重新审核变化部分，而无需从零开始验证。在设备群的整个生命周期中，验收矩阵与已知限制记录会成为支持团队、IT 团队和审批方共同使用的参照，这正是后续采购与最初获准配置版本保持一致的基础。