设计灵活的FOTA

FOTA（Firmware Over-The-Air）是你敢于用互联网思维做硬件产品的根本保障。只有灵活可靠的FOTA撑腰，发布前的bug评审会上，你才有底气说“非关键bug，升级解决”。

FOTA的需求有哪些？以下是粗略想到的：

1. Server被hack了、管理员脑抽……总之……云端搞错了升级包，不允许升级；
2. 传输错误的升级包，不允许升级；
3. 非官方发布的升级包，不允许升级；
4. 机型、硬件版本不匹配的升级包，不允许相互升级；
5. 客制化软件（比如销售地域、语言、运营商等），不允许相互升级；
6. 大的改动，导致1.0直接升级到3.0会挂掉，必须1.0先升级到2.0、2.0再升级到3.0；
7. Beta测试版本，如果有Bug让用户不能忍，允许降级到最新的稳定版；
8. Costdown机型，可以免编译重新制作升级包，机型、版本等信息显示正常；
9. 保存数据的格式改变，升级阶段能完成格式转换；
10. 升级镜像可能有多个；
11. 升级防变砖。

以上场景，提炼得出：

1. 升级包要自带校验信息；
2. MD5校验完整性；
3. RSA签名防伪造；
4. HW_ID：统一区分硬件差异，包括机型、硬件版本、其他客制化（比如销售地域、语言、运营商等）；
5. UG_VER：使用该升级包的最低软件版本要求；
6. DG_VER：当前运行软件允许降级到的最低版本；
7. 升级校验信息，不在编译期生成，而在打包时添加；
8. 机型、版本等参数，分成两份，严格区分开前端显示参数、后端校验参数；
9. pre-script/post-script可以为一些特殊需求提供便利，比如数据转换；
10. 多段升级镜像，可以通过TLV格式拼在一起；
11. 升级防变砖是另一个主题，一般双镜像备份。

FOTA的完整流程包括以下几个步骤：

1. 从云端下载升级包；
2. 使用包头信息，对升级包各种校验，校验失败就不允许升级；
3. 解开升级包；
4. 升级预处理pre-script；
5. 升级写入；
6. 升级后处理post-script。
   至此，升级完成。