OTA-扫盲

文章目录

• 前言
• 一、种类划分
• 三、OTA升级log
• 三、OTA包制作
  • full包
  • 差分包
• 总结

---

前言

OTA(over the air)一种通过空中下载技术下载升级的方式，指的通常是使用wifi或者数据流量的方式从服务器中将升级包下载到本地升级的一种方式；但是本地使用OTA包的升方式，我们也可以称之为OTA升级（概念的扩展），简单理解起来只要是使用制作出来的升级包去升级的过程我们统称为OTA升级。

一、种类划分

按升级方式的不同，可分为：在线升级和本地升级

按升级载体的不同，可分为：在线升级、T卡升级、adb升级

按升级包类型不同，可分为：增量(incremental update)升级和整包(full update)升级

命名方式：差分包、增量包、升级包、降级包、整包

1.1 在线升级

在线升级简单来说，就是将升级包上传至服务器端，然后机器通过连接wifi或者数据流量从服务器端将升级包下载到手机中进行升级的一种方式；这种升级方式需要配置对应的指纹信息或者IMEI号等，保证手机可搜索到包，以及搜索到包的正确性，这种方式是用户通常升级版本最常用的方式，整个流程需要经过对应的服务器端->framework框架层->recovery升级阶段。

1.2 T卡升级

T卡升级其实也可以称为本地升级，它是将升级包放置到T卡中进行升级的一种方式，通常的T卡升级可以从两个入口进行升级，分别是：1、正常模式下的设置模块自定义的system update升级入口；2、进入recovery模式下选择”apply update from sdcard”

1.3 sideload升级

adb升级其实也是本地升级的一种，因为升级包都是离线状态下取到的，不需要从服务器端下载，它的方式其实也有两种：1、正常模式下，保证adb端口正常直接执行adb reboot recovery sideload xx/xx/xx.zip；2、recovery模式下，选择”apply update from adb”菜单后，通过执行adb sideload xx/xx/xx.zip命令进行升级。

1.4 升级结果

1.4.1 关注升级过程：

在安卓7.0之前，升级的过程谷歌原生UI主要以绿色小机器人作为标记，当然OEM厂商也可以自己design，这种谷歌原生方式在升级过程中如果出现报错会有小机器人倒下等提示，如果是直接进recovery模式会有log提示升级失败字样，这种情况一定可以确定升级失败（下图是在项目上找到的升级失败的截图，ui同事已经对其做了替换，利用这种ui提示代表升级失败）

1.4.2 关注升级结果：

当第一种情况已经可以确认升级失败了，那么第二点就不用参考，否则在第一种情况未出现异常后，需要关注第二点的表现。升级后的结果主要指的是升级完成后，重启开机，如果能够正常开机，再检查对应各项内容是否升级成功，比如版本号是否更新、应用是否更新等情况。如果升级完成之后，无法开机，可以直接将机器拿到升级模块负责同事，检查升级过程是否有异常，如果没有异常交由开机启动模式分析为什么无法开机，升级同事负责协助；如果升级完成后，能够正常开机，检查对应的版本号等已更新，但是会出现应用报错、或者页面布局存在异常，需要将问题直接反馈到模块负责同事

二、OTA升级log

2.1 MTK上层log

适用场景：针对的就是在线升级方式导致的升级失败或者是本地T卡升级从设置模块的system update入口选择升级导致的升级失败，对于这两种方式升级失败问题，要求升级前打开MTK log进行升级，升级失败后提供对应的MTK LOG，再通俗点理解就是凡是在正常模式下启动的升级流程都需要提供MTK LOG。

抓取方法：确认版本是否是user版本。userdebug版本和eng版本默认开启MTK LOG，如果是user版本，可以使用工程指令：调出log界面，选择启动即可。默认将mtklog存放到内置sdcard里面去了，其实如果你插入外置T卡，也可以选择将log保存在外置T卡里面，除此之外还可以选择保存哪些log，假设是保存在内置T卡里面，可以使用MTP的方式拷贝MTKlog出来或者是执行命令：adb pull /sdcard/mtklog d:mtklog\即可，存放的地方可以自己定义，抓取后再出现异常后，提供给研发同事。

2.2 Recovery升级log

解释：主要指的就是升级过程中打印出来的log，该log是进入recovery模式后打印出来的，与正常模式下的mtklog是完全不同的，存放于cache分区中，需要单独抓取。

适用场景：任何升级失败场景

抓取方法1：进人recovery模式提供log截图，操作方法是进人recovery界面，或者当前已处在recovery模式下的时候，找到下面的菜单位置，按power键进入，进入后发现会有下面截图所示，有last_log和last_kmsg字样，对于简单的升级来说，只需要进入last_log，按音量下键往下翻页，直到看到类似failed字样，或者是进度条拉到大概90%到100%左右处截图提供，有些时候last_log会不止一个，有last_log1/last_log2等，这个时候需要测试同事同时关注下last_log和last_log1。

抓取方法2：提供cache分区，这种方式可以提供更全的升级log，需要掌握下载工具dump cache分区的操作。

2.3 cache分区dump流程

A、打开工具界面后，选择ReadBackA、打开工具界面后，选择ReadBack

B、选择ReadBack后会看到下面的截图界面，按照提示选择Add

C、选择 Add之后，会出现下面截图所示界面，双击截图位置

D、双击之后会弹出一个框，需要填写镜像文件的名称和存放位置，保存

E、保存按钮点击后，会再次弹出新的框，如下所示，最关键的地方也是在这里，这里需要填写dump的镜像文件的起始地址和size大小，一开始默认都是全0

F、镜像文件的起始地址和长度可以从下载版本中的scatter.txt里面获取，如dump cache分区，就需要找到cache分区所在位置，填写如下两个值到对应上面的框图中

G、填写后，就如下图所示，点击OK按钮

H、 配置完成后，就可以点击Read Back按钮，成灰显状态后，手机关机插USB，即可完成分区的dump过程，最终dump完成后如下截图所示，从之前存放的位置选择dump出来的cache.img提供即可

三、OTA包制作

3.1 full包编译

方式1：

A、执行source tran_setenv.sh xx user/userdebug/eng efuse

B、编译整个工程，执行make -j24 2>&1 | tee build.log

C、签名镜像文件，执行./vendor/mediatek/proprietary/scripts/sign-image/sign_image.sh【重点：这一步一定要先操作】

D、执行做包指令，make otapackage -j24 2>&1 | tee ota.txt，按照正常的这种流程操作完毕后，会在对应的项目路径下面生成对应的full包

方式2：

A、make otapackage命令除了是生成full包之外，还会在对应的该目录下生成target_files目录，如果没有执行make otapackage这一命令，是不会有该目录的，该目录下面的zip包也是用来制作差分包的基础版本

B、有了上述的target包之后，就可以直接通过调用脚本指令制作full包，执行： ./build/tools/releasetools/ota_from_target_files -k vendor/commonconfig/security/releasekey -s vendor/mediatek/proprietary/scripts/releasetools/mt_ota_from_target_files.py full_xx-target_files-xx.zip Tcard.zip

3.2 full包生成

build/core/Makefile：

定义了一个伪目标otapackage，它依赖于INTERNAL_OTA_PACKAGE_TARGET，而该文件就是制作OTA整包最后的生成文件，它的命名方式如下，生成位置在PRODUCT_OUT目录下，命名为$(name).zip，而name是等于$(name)-ota-$(FILE_NAME_TAG)，主要有三部分组成：TARGET_PRODUCT，这个在一开始source的时候就会确定，TARGET_BUILD_TYPE一般情况下都是定义成release，FILE_NAME_TAG这个变量在main.mk里面有定义，会根据HAS_BUILD_NUMBER宏来进行区分，最后本地生成的整包名字

BUILT_TARGET_FILES_PACKAGE的生成： 它是生成整包所需的中间文件。最后生成位置位于路径out\target\product\xx\obj\PACKAGING\target_files_intermediates\xx-target_files-xx.zip

（1）清理以前残存的目录和文件，并创建$(zip_root)目录，即对应的out\target\product\xx\obj\PACKAGING\target_files_intermediates\<product>-target_files-xx

（2）创建$(zip_root)/RECOVERY目录，把out/target/product/xx/recovery/root下的所有文件和目录拷贝到$(zip_root)/RECOVERY，还有out/target/product/xx目录下的其它目录文件如cmdline/second/kernel等到对应的$(zip_root)/RECOVERY目录下

（3）创建$(zip_root)/BOOT目录，并拷贝对应的内容到该目录下，同 recovery，后面类似的还会创建SYSTEM/RADIO/VENDOR/OTA/META等目录，其中需要重点关注的是META和OTA目录，META目录下面会生成很多txt文件，这些文件对于制作升级包会强相关，OTA目录下面主要是包含了升级过程中需要的升级函数实现的可执行文件

…………………… ……………………

ota_from_target_files.py脚本

(1) main函数参数解析

(2) 从中间的zip包里面的META/misc_info.txt中 解析出对应的参数，例如key,tool_extensions等，OPTIONS.extracted_input就是前面Makefile中通过” --extracted_input_target_files”指定的target中间包，其中解析的misc_info.txt里面的内容主要是赋给OPTIONS.info_dict；

(3) 从OPTIONS对里找到tool_extensions赋值给OPTIONS.device_specific，这是假定如果没有指定”-s”参数的话，如果指定了就直接从指定的py脚本中获取

(4) input_zip为上文中的zip包，out_zip为最终生成的临时zip包，对于整包的话会调用WriteFullOTAPackage(input_zip,  output_file=args[1])函数来生成

(5)调用SignOutput签名临时包，生成最终的全包升级包

 WriteFullOTAPackage函数实现

(1) 生成Edify脚本，主要在EdifyGenerator.py里面实现，在这里面实现的都是各种升级过程中的处理命令，写到对应的update-script脚本里面

(2) 调用GetPackageMetadata函数获取对应的元数据内容，最后会将这些内容写到升级包里面

(3) 获取对应的版本里面的编译时间，为日后升级过程中做校验使用，也就是说T卡包在升级的时候是会校验时间戳的，它不允许后往后倒退升级

(4)设置对应的进度条处理脚本，通过script的ShowProgress实现

（5）获取boot分区内容，对system和vendor分区进行处理生成对应升级所需内容，其中AddCompatibilityArchiveIfTrebleEnabled主要是将system和vendor下面的一些 xml文件写入升级包中，这些xml文件是treble使能后新增的，主要用于升级过程中校验，在升级过程中会获取手机里面的信息与之作比较

（6）对boot分区进行整个镜像的内容写入，在升级过程中会整个覆盖写入boot分区

（7）preloader、lk、modem等其它特殊分区的处理

releasetools.py脚本

A、根据是否是整包往升级包中type.txt里面写入对应的值，读取OTA目录下面的ota_update_list.txt内容写入到scatter.txt里面，放入升级包中，对于type.txt文件最后升级的时候其实并没有应用到，但是scatter.txt里面在升级过程中会有用到

B、check-bootloader_path函数主要针对preloader做处理，它会判断对应的存储芯片类型是否是ufs，通过ro.vendor.mtk_ufs_support=1宏来决定，这样做的目的是因为ufs和emmc对应的preloader的设备路径是不同的，如果不做区分升级preloader分区的时候就存在问题

C、AddOTAImage_Items函数就是真正对除常用分区外其他分区进行处理的关键部分，它会读取ota_update_list.txt里面待升级的分区，然后根据不同类型进行区分，最终写入到升级包中脚本中，主要就是区分两类，其中dtbo md1img spmfw vbmeta作为一类，直接写入对应的设备路径；sspm tee scp preloader需要同时写入对应的源和备份设备路径，也就是所定义的1和2

（8）判断是否有额外脚本选项指定，以及判断是否指定了擦除用户数据，也就是-w，如果指定了的话，调用script的FormatPartition函数对data分区进行格式化的写命令处理

（9）调用FinalizeMetadata函数进行处理，这里面会将metadata文件写入升级包中的META-INF/com/android/metadata位置，再调用SignOutput函数完成版本的签名操作，最终到此完成这个升级包的制作

3.3 差分包编译

所谓的差分包，其实就是使用两个版本之间的差异生成一种只针对差异化更新的增量升级包，这种升级包与full包的不同之处在于它更小，而差异化的地方多通过patch的方式升级，升级速度更快，对于手机所要求的存储空间低。要生成差分包，就需要有两个不同版本的target文件，因此上述full包的操作流程需要在两个版本间都执行过一次，获取到最终两个版本间的target文件，再通过target文件进行差分操作。

编译命令： ./build/tools/releasetools/ota_from_target_files -k vendor/commonconfig/security/releasekey -s vendor/mediatek/proprietary/scripts/releasetools/mt_ota_from_target_files.py -i full_xx-target_files-xx.zip full_xxx-target_files-xxx.zip Increment-ota.zip

差分包的命令目前O版本和P版本存在差异：

O版本：. ./build/tools/releasetools/ota_from_target_files -k vendor/commonconfig/security/releasekey -s vendor/mediatek/proprietary/scripts/releasetools/mt_ota_from_target_files -i V1.zip V2.zip update.zip

P版本：./build/tools/releasetools/ota_from_target_files -k vendor/commonconfig/security/releasekey -i V1.zip V2.zip update.zip 接下来就上述指令简单分析下差分包的生成流程，其中”蓝色字体”表示选项可添加也可不添加，”红色参数”表示必须添加。同full包一样，差分包的生成也主要是通过ota_from_target_files.py脚本生成，只不过在处理的地方稍有差异。

3.4 差分包生成

main主函数执行过程：

（1）从参数和环境中解析OPTIONS，同full包，前面提到过”-k”参数是可有可无的，但是如果指定的话，就会将指定的路径key赋给OPTIONS.package_key，同时如果指定了”-i”参数就将后面跟着的版本赋给OPTIONS.incremental_source

（2）加载读取升级包中的misc_info.txt里面的内容，同上full包，只不过相较于full包，它这个工作需要做两次，会同时获取源target和目标target分别赋给OPTIONS.target_info_dict以及OPTIONS.info_dict后面在升级包处理过程中都会用到

（3）调用common.py脚本里面的UnzipTemp解压函数解压target zip文件，同时也会载入对应是device_specific脚本，如果没有通过-s命令指定的话，就会默认从META目录下面获取，将releasetools.py作为默认脚本

（4）再次解压source zip，调用WriteBlockIncrementalOTAPackage脚本实现差分包的处理

WriteBlockIncrementalOTAPackage执行流程：

（1）生成Edify脚本，主要在EdifyGenerator.py里面实现，在这里面实现的都是各种升级过程中的处理命令，写到对应的update-script脚本里面

（2）获取对应的源和目标boot内容，主要是从IMAGES/目录下获取对应的boot.img内容，同时获取对应的目标recovery内容

（3）调用common.py脚本的GetSparseImage函数获取对应的system内容中的block数据，源target和目标target都要获取分别赋给system_src和system_tgt，最后调用common.py脚本中的BlockDifference类对其进行差异化block处理，最终调用的是blockimgdiff.py里面的BlockImageDiff函数，这里面集成的都是基于bsdiff的算法

（4）接下来针对vendor分区的处理过程，它的处理方式和system分区一样，只不过执行的时候会首先判断是否存在分区，由于block的升级在安卓6.0就支持了，而当时其实谷歌对于treble这块还未有介绍，所以vendor分区作为一个非必须存在分区，主要由芯片厂商或者手机厂商自行决定，而谷歌的代码则会照顾到vendor分区有或者无的情况，因此添加了是否存在vendor分区的判断，这个判断一直沿用至今也没有去掉

（5）接下来会调用WriteFingerprintAssertion函数获取对应的fingerprint写入脚本中，升级过程中会去校验该属性，同时会根据system和vendor在差分过程中所要求的cache size大小追加到size列表里面，后面会将要求的值写入到对应的metadata里面，在升级过程中也会检测cache分区空间的剩余大小是否满足要求

（6）接下来对boot分区进行处理，会去计算source boot 和target boot之间的差异性，如果差异太大导致出错就会将boot分区作为整个镜像文件升级处理，反之则会直接根据source和target的boot.img进行差分生成boot.img.p写入到升级包中，升级的时候就会将boot分区做patch升级，在升级前还是会做patch check的动作，检查手机版本中的哈希是否满足要求，如果不一致则报错处理，这就要求升级包的制作一定要是下载到手机中的源版本和另一个目标版本之间的差分

（7）对于非主要的ap侧分区以及引导分区的升级都在对应的device_specific脚本里面的IncrementalOTA_InstallEnd里面完成，这个过程前面在full包中有介绍，过程类似，差异性也有但是不多，感兴趣可以自己去看代码，不作重复介绍（7）对于非主要的ap侧分区以及引导分区的升级都在对应的device_specific脚本里面的IncrementalOTA_InstallEnd里面完成，这个过程前面在full包中有介绍，过程类似，差异性也有但是不多，感兴趣可以自己去看代码，不作重复介绍

（8）和full包不同之处还有一点，它支持所谓的降级处理，也就是制作升级包的时候指定--downgrade参数，指定该参数可以允许你升级到一个比你源版本时间旧的版本，但是一个重要影响它会擦除data分区，即用户数据，所以该选项慎用

（9）最后一步也是和full包一样，需要对其进行签名操作，实现同上full包具体过程也可以查看FinalizeMetadata的实现

签名命令：

java -Xmx2048m -Djava.library.path=out/host/linux-x86/lib64 -jar out/host/linux-x86/framework/signapk.jar -w vendor/tran_os/security/releasekey.x509.pem vendor/tran_os/security/releasekey.pk8 /tmp/tmpMvN4L7 out/target/product/ka7_h8024/full_ka7_h8024-ota-1542863682.zip

---

总结

对于初学者，此文章可以帮忙快速扫盲，当然任何技术上的精进都是建立在基础之上。如果一些简单的名词或者说法都不清楚，一切都是空谈。了解此篇后，就可以更深层次的学习，加油，未来可期！