fota 差分包_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

---------------------

本文来自 慌慌丨张张 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/s762888517/article/details/53994688?utm_source=copy