09-安卓工控固件版本管理：OTA升级包、差分升级、固件版本回溯

09-安卓工控固件版本管理OTA升级包、差分升级、固件版本回溯大家好我是黒漂技术佬。今天我们来聊一个在无人售货柜落地过程中搞死过无数工程师的问题——固件版本管理。想象一下你凌晨三点被报警电话吵醒全国300台售货柜同时卡在开机logo因为昨晚推送的OTA包里有一个驱动不兼容。这时候你只有两个选择要么连夜驱车几百公里一台台刷机要么冷静地执行版本回溯。显然后者才是专业选手的打法。一、为什么固件版本管理这么要命一台典型的无人售货柜安卓工控机运行的不只是一个APK。它背后是一整套固件生态BootLoader、Linux Kernel、Android Framework、HAL驱动层、各种Native服务。售货柜还额外接了重力传感器、温控模块、4G通信模组、门锁电机等外设。这些组件之间有着复杂的版本依赖关系。一旦某个模块升级后与旧版驱动不兼容或者新内核没有适配特定的LCD屏整个设备就会变成一块砖头。所以固件版本管理不是给ROM包编个号那么简单而是一套包含OTA升级、差分增量、签名校验、版本回溯、A/B分区的系统工程。二、OTA升级包不只是打个zip那么简单OTAOver-The-Air升级包的完整制作流程如下步骤1编译基线固件CI流水线构建全量固件镜像包括system.img、vendor.img、boot.img、dtbo.img等分区镜像。步骤2生成OTA包使用Android自带的ota_from_target_files工具将两个版本的固件差异打包成OTA zip./build/tools/releasetools/ota_from_target_files\-iold_target_files.zip\new_target_files.zip\update.zip步骤3签名校验这是最容易被忽略但最关键的一步。OTA包必须经过两级签名OTA签名使用signapk.jar对整个OTA包签名确保升级包来源可信分区签名Android Verified Boot (AVB) 机制会校验每个分区的hash和签名我把签名证书锁在一个离线机器上CI构建完成后通过物理U盘拷过去签名。虽然麻烦但这是防止签名证书泄露的底线。步骤4分发到设备OTA包通过MQTT推送到设备端设备端下载后先校验MD5再进入Recovery模式刷入。三、差分升级增量包省流量的秘密武器全量OTA包动辄500MB-1GB售货柜用的是4G流量卡每台每月流量预算只有2GB。如果每次升级都推全量包流量费用比售货柜赚的钱还多。差分升级的原理很简单只下发新旧版本之间的差异数据设备端本地合成完整新版本。底层用的是bsdiff算法或Android的block-based OTA旧文件: [A][B][C][D][E][F] 新文件: [A][B][X][D][E][G] 差分包只包含: - COPY: 偏移0, 长度2字节 (AB) - INSERT: [X] - COPY: 偏移3, 长度2字节 (DE) - INSERT: [G]实际操作中我们在设备端做applypatch操作把差分包打到当前分区的block设备上。增量包通常只有全量包的10%-20%对节省流量效果显著。实战TIPS差分升级有累积风险。连续做10次增量升级和直接刷全量包的结果可能不一致浮点精度、文件权限。我们的做法是每5个增量版本后强制出一个全量包确保版本基线可控。四、A/B分区与版本回溯为容错而生传统升级方式叫非A/B升级设备进入Recovery模式把OTA包刷到唯一的系统分区。如果刷到一半断电设备就挂了。A/B分区的思路很简单设备上有两份系统分区——slot_a和slot_b。当前系统跑在slot_a上的时候OTA更新把新系统写到slot_b。升级完成后boot_control把启动标记切换到slot_b下次开机直接起新系统。A/B方案最大的好处不是无缝升级而是版本回溯。如果新系统启动连续失败比如卡在boot animation超过N次bootloader会自动切回旧分区。这就是安全网机制。我们售货柜项目具体做法# 查看当前启动slotbootctl get-current-slot# 标记新slot启动成功bootctl mark-boot-successful在Android Init.rc里加一个on property:sys.boot_completed1触发器启动成功后执行mark-boot-successful。这样如果启动过程中崩溃bootloader就不会收到成功标记下次自动回退。五、无人售货柜OTA实战经验说几个我们踩过的坑分区表前后兼容固件迭代过程中如果改了分区表比如扩大了vendor分区差分包可能刷不进去。解决方案是设计之初就预留足够的分区空间。4G弱网环境售货柜经常放在地下室或信号死角。OTA下载必须支持断点续传我们用Range请求分段下载每段校验MD5。外设固件的版本绑定MCU门锁控制板的固件也需要配合主控升级。我们设计了一个固件兼容版本号字段主控启动后检查MCU版本不匹配就通过串口触发MCU自身升级。设备自检与心跳每次OTA后设备自动跑一遍自检脚本——测试摄像头、称重传感器、门锁、支付模块。自检通过才上报升级成功。版本管理这事本质是给每一种故障情况都准备好退路。全量包、增量包、A/B分区、签名校验、版本回溯——这些机制组合在一起才能让千里之外的设备即使出了问题也能自己爬起来。好了去检查一下你们的OTA日志说不定设备们正在默默感谢你留了后路呢。我是黒漂技术佬下回见。