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。
至此，升級完成。
