Android OTA升级原理 - 实现流程(整理一)

最新推荐文章于 2025-04-14 20:02:33 发布

sevencheng798

最新推荐文章于 2025-04-14 20:02:33 发布

阅读量2w

点赞数 7

分类专栏： Android 文章标签： android ota

本文链接：https://blog.csdn.net/sevenjoin/article/details/105052755

版权

Android 专栏收录该内容

8 篇文章

订阅专栏

本文深入解析Android OTA（Over-the-Air Technology）升级流程，涵盖升级包制作、设备分区写入及工作模式等内容，适合Android系统开发者及对OTA升级感兴趣的读者。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

OTA升级概述

OTA（Over-the-AirTechnology）是指手机终端通过无线网络下载远程服务器上的升级包，对系统或应用进行升级的技术。有关网络部分不做过多讨论，本文重点放在系统升级这一概念上。

目前主要分为两大类：

按照升级的方式可以分为：T卡升级和网络升级
按照包的内容可以分为：增量升级和整包升级

那么对于设备来说我们需要考虑几点：

升级包是怎么产生的
升级包是怎么写入设备对应的分区的。

制作升级包

对于Android系统升级包制作主要分两种：

一种是通过命令自动产出全包和增量包；
另一种是在之前升级包的基础(通常是增量包)上进行修改/增加新的内容；
实际上第二种是对第一种的补充方式。

自动生成update.zip升级包

这种方式就是通过Android提供的编译指令进行自动制作。
该方法主要概括为以下几个步骤：

make  # 先编译Android源码
make otapackage  # 开始制作ota全量包
# 制作差分包， 这一步需要准备基包base.zip, target_files.zip是刚刚生成的包， update.zip就是基于前面两个包产生的增量包，用于后面升级使用
./build/tools/releasetools/ota_from_target_files -k build/target/product/security/testkey -s vendor/mediatek/proprietary/scripts/releasetools/mt_ota_from_target_files --block -i base.zip target_files.zip update.zip

注:
以上步骤是制作升级包的大概步骤，具体细节请各位自行搜索，网上资料实在太多了。

手动生成update升级包

这种模式通常情况下在改动很小或者只更新了某几个APK应用程序，不想再重新make otapackage的情况下采用的。
该方法主要概括以下几个步骤：

# 1.将现有的update.zip解压
# 2.将改动的apk替换到system/app或者其他具体的工作目录中
# 3.重新打包成update.zip， 打包的时候不能有二级目录，即解压后直接就是内容
# 4.对新的update.zip重新签名 - 必须做， 重新签名的指令如下：
java -Djava.library.path=out/host/linux-x86/lib64 \
    -jar out/host/linux-x86/framework/signapk.jar \
    -w build/target/product/security/testkey.x509.pem \
    build/target/product/security/testkey.pk8 update.zip update-new.zip

注:
1.以上步骤是制作升级包的大概步骤，具体细节请各位自行搜索，网上资料实在太多了。
2.网上有的资料提供的签名指令，没有增加-Djava.library.path=out/host/linux-x86/lib64这一句，导致签名失败，如果有遇到签名失败问题，可以加上试试。

增量包目录结构

制作好的update.zip结构通常如下：不同的平台可能有稍许差异
├── lk.img
├── META-INF
│ └── com
│ ├── android
│ │ ├── metadata
│ │ └── otacert
│ └── google
│ └── android
│ ├── update-binary
│ └── updater-script
├── odmdtbo.img
├── patch
│ └── boot.img.p
├── scatter.txt
├── system.new.dat
├── system.patch.dat
├── system.transfer.list
├── tee.img
├── type.txt
├── vendor.new.dat
├── vendor.patch.dat
└── vendor.transfer.list
其中有两个文件需要说明一下，这个和后面升级会用到：

update-binary 是一个二进制文件，相当于一个脚本解释器，它定义描述了updater-script中所使用的语法行为，即最终实现的操作。该文件在Android源码编译后被放置在out/target/product/<TARGET_TYPE>/system bin/updater，在做make otapackage时会将updater重命名为update-binary并放置到META-INF\com\google\android这个目录中。
源码位置在：bootable\recovery\updater中
update-script 此文件是一个脚本文件，具体描述了更新过程。我们可以根据具体情况编写该脚本来适应我们的具体需求。它的语法是在update-binary中定义的。这个脚本也是我们后续会被改动的，比如我们需要增加一个自定义的更新，我们就可以手动增加重新打包签名。

升级包写入设备分区

这里也是最重要核心的地方，设备是如何开始升级的。首先我们需要知道Android设备的几种工作模式

Android的三种工作模式

主要有三种：

正常模式
Recovery 模式
Fastboot模式

在这里插入图片描述
由上图可以知道如何进入不同的模式：

正常启动模式：用户什么都没有操作，开机将自动进入该模式。
Recovery 模式：可以有两种种方式：
[1] 开机时按下home+power组合键
[2] 在正常模式下通过reboot recovery命令进入
fastboot：快速刷机模式：开机时按下camera+home组合键

Recovery升级模式

在前面我们制作的ota升级包就是需要在该模式下完成升级操作。

正常的升级流程如下图：
在这里插入图片描述
这是一个从APP一路执行到底层的大概流程。在这我们只需要通过命令模拟从APP到framework的过程来验证recovery 升级。
首先需要知道APP - Framework做了什么事情；简单可以概括为：从APP接收到升级包并获取完整路径，给到framework，然后framework将进行校验是否合法，然后再对/cache/recovery目录相关历史记录做清除操作，并写入接收到的完整路径到command文件中，最后通过reboot recovery让设备重启进入升级模式。
所以我们只需要模拟这一过程就可以：