FOTA升级

分以下三个模块分析FOTA升级介绍

        1.在一个高通安卓项目中部署FOTA升级 

        2.Android ota升级的基本过程 

        3.Android ota升级异常分析 

升级:

    从方法上分为整个文件替换，以打patch的方式替换 (diff patch)
    从是否借助外部设备上分为借助外部设备,不借助外部设备  

        1.借助外部设备升级（PC 的fastboot升级，设备芯片的直接烧录）

         2.不借助外部设备升级,一般都有自己特定的升级模式进行升级（Android Fota升级 , 应用市场应用升级FOTA升级） 

Firmware Over-The-Air 固件空中下载技术，主要用于应用的手机领域.

    在FOTA升级出现之前手机制造商和移动网络运营商无法在手机的最重要的18至24个月内进行有效的软件升级.

    FOTA升级应用领域:需要后续升级维护的设备 比如:手机,平板,车载,物联网等Android 

    FOTA升级特点 1.升级system系统应用 2.升级固件,modem sbl1 tz rpm lk boot.img设备 3.生产厂商专属！

Firmware：固件 设备通电之后，进行初始化让元器件正常运行的二进制程序。
                 ： rpm高通的资源功耗管理子系统
                 ：sbl1 高通的bootlodaer
                 ：tz高通安全模块
                 ：emmc_appsboot android的bootloader
                 ： NON-HLOS调制解调(基带)处理子系统

 芯片厂商提供的很多参数，设备生产厂商根据设备特点配置出来的最合适的硬件参数---固件
如何在一个android项目里部署fota升级
    1.本地编译版本，成功制作ota包
    2.移植对应厂商的ota移植数据
    3.实现本地FOTA升级验证
    4.终端APP界面开发
    5.升级服务器开发
    6.实现一键升级验证

差分包相关  1.升级包编译 2.制作差分包  //3.差分包重签名
升级包编译

    在android目录
    执行 source config.sh
    Make otapackage 
    升级包生成路径out/target/product/{product_name}/ {product_name}-ota-eng.{uid}.zip

添加高通的固件移植就是把编译好了的rpmemmc_aboottz sbl1 NON-HLOS固件添加到与差分包制作相关的文件

制作差分包

与差分包制作相关的文件

    ota_from_target_files

    releasetools.py   

    ota_target_files.zip    -----对package_backup.zip的打包

    releasekey.pk8/ releasekey.x509.pem签名文件

文件路径/device/qcom/common/releasetools.py

    通过修改该文件可以实现对分区进行整包/差分升级配置
    tz rpm emmc_aboot NON-HLOSsbl1
文件路径/build/tools/releasetools/ota_from_target_files

    通过修改该文件可以实现对boot.img的整包差分升级

关于ota_from_target_files脚本

    ./build/tools/releasetools/ota_from_target_files –d MMC -p ./out/host/linux-x86    

     -k ./build/target/product/security/testkey–Ipath_to_target_files_v1.zip 

    path_to_target_files_v1.zip update.zip

    部分参数
    -k  签名文件路径
    -i  从v1 升级v2的增量构建
     -w 升级结束后对userdata分区进行初始化
    -d 选择设备类型
    -p 对应的工具路径

update1.zip\META-INF\com\google\android\updater-script升级脚本

updater-script()

    1.mountsystem (重新挂载使得可以写)
    2.校验是否是对应的属性/签名 自制ROM
    3. apply_patch_check 校验
    4. apply_patch打path
    5. set_metadata  恢复文件信息
    6.radio update tasks 升级固件
    7.unmount system
FOTA本地验证升级
    adb  root
    adb push update.zip /data/update.zip
    adbshell mkdir/cache/recovery
    adbshell “echo –update_package=/data/update.zip >/cache/recovery/command”
    adb shell sync      //同步文件系统
    adb reboot recovery  
Androidota升级的基本过程
Emmc_aboot启动recovery
    1.判断是否进入fastboot模式
    2.判断加载boot.img  /recovery.img   misc分区！
    3.加载recovery.img
    4.执行recovery的init.rc   
    执行service recovery /sbin/recovery seclabel u:r:recovery:s0
 注： (/bootable/recovery/etc/init.rc)

Recovery.cpp
    Recovery模式 recovery的init.rc   (/bootable/recovery/etc/init.rc)
    执行recovery.cpp进程 
    Get_args 获取command的参数 if not 就等输入
    ---- 跑跑跑      注意：恢复出厂设置也在这里！
    加载 META-INF\com\google\android\updater-binary
    创建新的进程updater-binary
    建立recovery进程与updater进程的管道
    recovery进程作为显示 updater进程解析updater-script 并且升级
    升级结束,清楚标志位

第三方升级支持做了什么：
    1.技术支持（升级有问题可以问他们）
    2.提供升级服务器 --（AWS）
    3.简化的操作的工具 -- 一键上传
Androidota升级异常分析:
两个日志,一个文件
    –/cache/recovery/last_log看升级过程异常
    –Fota_log  与升级服务器交互的log
    –saved.file升级过程中bak文件
一个工具
    –QMSCT导出设备镜像
    –dd if=/dev/block/bootdevice/by-name/modemof=/sdcard/modem.mbn
两个问题：
    现象：设备升级结束后可以正常开机但报严重错误
    问题分析：
–升级modem时设备异常重启！
–Apply_check check失败 退出recovery
–release_tool 添加参数
    原因Apply_check函数解析脚本时会把对应文件的hex值加入list
    由于modem已经被破坏（hex有问题），寻找saved.file时又没有对应hex与其匹配
    处理办法 修改release_tool脚本,添加对应参数
    现象：设备升级结束后可以正常开机但报严重错误
    问题分析：
–升级modem时设备异常重启！
–Apply_check check失败 退出recovery
–release_tool 添加参数
    原因Apply_check函数解析脚本时会把对应文件的hex值加入list
    由于modem已经被破坏（hex有问题），寻找saved.file时又没有对应hex与其匹配
    处理办法 修改release_tool脚本,添加对应参数

相关链接：http://blog.csdn.net/mu0206mu/article/details/7399822