分以下三个模块分析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脚本,添加对应参数
