解读

面试官抛出 OTA 话题，通常想验证三件事：

1. 你是否真正理解 Android 整个链路——从 AOSP 编译服务器到设备端 update_engine 的闭环；
2. 你是否能把“手机那套”无缝迁移到碎片化更严重的 IoT 硬件（电视、车载、穿戴、家电）；
3. 你是否具备“可落地”的工程视角：差分包大小、断电保护、回滚策略、合规（国密算法、工信部入网要求）等。

回答时，先给一句话定义，再拆“端-管-云”三层的 Android 实现，最后落到 IoT 场景下的痛点与商业价值，就能体现深度。

知识点

1. OTA 本质：通过无线通道把新固件/系统镜像/应用静默送达终端，并在重启后完成原子升级。
2. Android 官方实现：
   • 云：Google 的 OTA 服务器或厂商自建 CDN，生成 payload.bin（完整包）与增量包（基于 bsdiff/imgdiff）。
   • 管：HTTPS + 断点续传，国内必须兼容双证书（RSA+SM2）以满足《密码法》要求。
   • 端：update_engine 进程，基于 A/B（无缝）或 Recovery（非无缝）升级；校验 payload 签名（RSA-4096/SHA-256 + verity 树），写入 /misc 后重启，失败自动回滚到 slot A/B。
3. IoT 特有约束：
   • 存储小（8 MB Nor Flash），需压缩到 KB 级差分包；
   • 电源不可靠，必须双 bank + 断电续升（Power-loss Safe Delta, PLSD）；
   • 网络异构：Wi-Fi Mesh、NB-IoT、485 总线，需做自适应分包（CoAP/MQTT）；
   • 合规：工信部 292 号文要求可溯源版本号、强制回滚窗口 ≤ 24 h；
   • 安全：TEE 里验签，防止“中间人+回滚攻击”，国密 SM2/SM3/SM4 已写入 AOSP 14 的 avb 流程。
4. 衡量指标：升级成功率 ≥ 99.5%、回滚率 ≤ 0.1%、包体积压缩率 ≥ 80%、断电恢复时间 ≤ 30 s。

答案

OTA（Over-the-Air）升级，指通过无线通道把系统镜像或固件推送到设备端，完成静默下载、校验、写入与重启的一整套闭环流程。在 Android 体系里，Google 通过 AOSP 的 update_engine 提供标准实现：云端生成 payload.bin，终端基于 A/B 分区或传统 Recovery 模式进行签名校验与原子升级；失败时利用 slot 回滚或救援分区保证设备不“变砖”。

在 IoT 场景下，OTA 的重要性体现在三方面：

1. 成本：海量设备散布全国，无法现场刷机，OTA 是唯一经济可行的维护手段；
2. 合规与安全：国内监管要求设备在发现漏洞 24 h 内具备可回滚的补丁能力，OTA 结合 TEE+国密验签可满足《密码法》与工信部 292 号文；
3. 体验与增值：通过差分压缩（80% 以上）、断电续升、双 bank 热更新，把升级成功率做到 99.5% 以上，既降低售后率，也为后续 AI 模型、付费功能订阅提供持续运营通道。

因此，OTA 是 Android IoT 产品全生命周期管理的“高速公路”，没有它就没有后期迭代与商业变现的可能。

拓展思考

1. 如果让你设计一个“8 MB Flash + 256 KB RAM”的蓝牙 Mesh 设备 OTA 方案，你会如何拆分 bootloader、压缩算法、断电续升状态机？
2. Android 14 引入了“虚拟 A/B with compression”，理论上可把差分包再降 30%，但压缩在设备端进行，CPU 与内存开销如何权衡？
3. 国内厂商常把 OTA 与广告 SDK 耦合，导致升级失败率升高；如果让你重构，你会如何把 update_engine 与三方 SDK 解耦，同时保持可回溯日志给工信部审核？