设计灵活的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。
    至此,升级完成。

推荐阅读更多精彩内容