FOTA（Firmware Over-The-Air）是你敢于用互联网思维做硬件产品的根本保障。只有灵活可靠的FOTA撑腰，发布前的bug评审会上，你才有底气说“非关键bug，升级解决”。
FOTA的需求有哪些？以下是粗略想到的：
- Server被hack了、管理员脑抽……总之……云端搞错了升级包，不允许升级；
- 传输错误的升级包，不允许升级；
- 非官方发布的升级包，不允许升级；
- 机型、硬件版本不匹配的升级包，不允许相互升级；
- 客制化软件（比如销售地域、语言、运营商等），不允许相互升级；
- 大的改动，导致1.0直接升级到3.0会挂掉，必须1.0先升级到2.0、2.0再升级到3.0；
- Beta测试版本，如果有Bug让用户不能忍，允许降级到最新的稳定版；
- Costdown机型，可以免编译重新制作升级包，机型、版本等信息显示正常；
- 保存数据的格式改变，升级阶段能完成格式转换；
- 升级镜像可能有多个；
- 升级防变砖。
以上场景，提炼得出：
- 升级包要自带校验信息；
- MD5校验完整性；
- RSA签名防伪造；
- HW_ID：统一区分硬件差异，包括机型、硬件版本、其他客制化（比如销售地域、语言、运营商等）；
- UG_VER：使用该升级包的最低软件版本要求；
- DG_VER：当前运行软件允许降级到的最低版本；
- 升级校验信息，不在编译期生成，而在打包时添加；
- 机型、版本等参数，分成两份，严格区分开前端显示参数、后端校验参数；
- pre-script/post-script可以为一些特殊需求提供便利，比如数据转换；
- 多段升级镜像，可以通过TLV格式拼在一起；
- 升级防变砖是另一个主题，一般双镜像备份。
FOTA的完整流程包括以下几个步骤：
- 从云端下载升级包；
- 使用包头信息，对升级包各种校验，校验失败就不允许升级；
- 解开升级包；
- 升级预处理pre-script；
- 升级写入；
- 升级后处理post-script。
至此，升级完成。
