Android OTA 升级（Over-The-Air）是一套复杂的系统更新机制。升级过程中涉及多个文件的解析、验证和分区的改动，甚至在不同升级模式下（A/B 分区或传统分区）设备内部文件和分区的变化也有很大不同。本文将从原理层面深入剖析升级的核心机制，并具体展示升级过程中 Android 系统内部文件及分区的变化。

本文基于梧桐MT8676的OTA升级流程编写

1. OTA 升级概览

OTA 升级的目标是将一组更新数据（称为升级包）应用到设备上，从而修复漏洞、优化性能或增加新功能。升级过程包括以下几个关键环节：

1. 下载升级包：通过 HTTP 或 HTTPS 协议下载包含新系统镜像的 ZIP 文件。

2. 校验完整性：验证升级包的文件哈希值与数字签名，确保数据未被篡改。

3. 解压与解析：提取 payload.bin 文件及其元数据。

4. 应用更新：将更新指令和数据写入到目标分区。

5. 切换分区或启动新系统：完成升级后的分区切换（A/B）或直接启动（非 A/B）。

2.  Android OTA 升级包内部结构与解析

2.1.  

OTA 包通常以 ZIP 格式分发，内容可能根据设备类型有所不同。典型内容如下：

OTA_Package.zip

├── payload.bin             # OTA 数据文件，包含所有分区更新的二进制数据

├── payload_properties.txt  # 描述 payload.bin 的元信息

├── compatibility.zip       # 兼容性信息（可选）

├── care_map.pb             # 分区校验的映射信息

├── metadata.txt            # 校验信息（哈希值和大小）

├── scripts/                # 脚本目录

│   ├── updater-script      # 执行更新指令

│   └── post-install        # 后处理脚本

2.2. 文件解析与功能

2.3. payload.bin 的深入分析

payload.bin 是 OTA 升级包的核心文件，其内部结构可以分为以下部分：

Manifest 内部的更新指令

Manifest 记录了 OTA 升级涉及的所有分区和每个分区的更新步骤，其常见指令包括：

· TYPE_ERASE：擦除目标分区的数据块。

· TYPE_REPLACE：直接将新数据写入分区。

· TYPE_BSDIFF：基于二进制差分算法，将差分数据块合成完整数据。

· TYPE_MOVE：将指定数据从一个存储区域移动到另一位置。

3. MT8676目前OTA升级方法

3.1. 获取OTA包

目前获取OTA包是从梧桐智联 获取到包上传到百度云盘 我们从百度云盘下载，下载得到文件

J90K-A023_OTA.zip

3.1.1. OTA包目录介绍

J90K-A023_OTA/

├── linux_upgrade/

├── ota/

├── resource/

└── tmp/

3.1.2. 目录详细说明

3.1.2.1. linux_upgrade

作用：

存放与 Linux 系统升级相关的文件。

内容包括： 

system_vm.img

dtbo_vm.img

boot_vm.img

ramdisk_vm.img

raite_mt8676-spm.img

3.1.2.2. ota

作用：

存放具体的 OTA 包和相关文件。

内容包括：

在章节2.1介绍过

3.1.2.3. resource/

作用：

存放资源文件，车机的相关资源。

内容包括：

WT_CarShow：专注于用户界面的视觉展示与功能模块。

WT_SmartSoundEffect：专注于音效处理与优化，提升车内音频体验。

3.1.2.4. 总结

其他目录如 tmp 下的 META、IMAGES、SYSTEM、VENDOR 等更多与系统分区和设备功能相关的内容，虽然在其他情况下可能是 OTA 升级的一部分，但在您的当前升级流程中，它们并不直接涉及。当前的升级过程只处理 payload.bin 和 payload_properties.txt 这两个文件，而其他文件夹中的内容（如系统镜像、厂商特定的固件等）在此过程中可能并不被使用。

3.2. OTA升级 操作

3.2.1. 上传文件到安卓data目录

adb push payload.bin /data

3.2.2. 调用update_engine_client进行升级

根据payload_properties.txt中的内容 替换以下内容，进行执行:

update_engine_client --payload=file:///data/payload.bin --update --headers="

FILE_HASH=uRrzwxA7dV8leorQxWmGYq2i4FaiALIx+7Y+8o/r1s8=

FILE_SIZE=4582346384

METADATA_HASH=aafnYHSZp7IzEjgz7r102IEZur7/+sBDy4iNE2efUyU=

METADATA_SIZE=166656"

3.2.3. 查看升级进度

通过执行命令  logcat | grep update_engine，即可看到

4. OTA 升级过程中的文件与分区变化

4.1. 文件操作与系统状态变化

在 OTA 升级过程中，Android 系统对文件和分区进行了一系列操作。以下是一个典型 OTA 升级的内部文件变化和逻辑步骤：

步骤 1：下载并推送升级包

· 文件变化：

OTA ZIP 包被下载到 /data/ 或 /cache/ 目录。

解压后，payload.bin 和元数据文件存储到指定路径（如 /data/ 或 /tmp/）。

· 系统状态：

系统处于正常运行状态，用户空间中运行升级进程。

步骤 2：校验文件完整性

· 文件变化：

使用 SHA-256 校验 payload.bin 和 metadata.txt 的哈希值。

校验文件大小是否与元数据记录一致。

· 系统状态：

如果校验失败，更新过程终止；如果成功，进入下一阶段。

步骤 3：解析并准备更新

· 文件变化：

update_engine 服务加载 payload.bin 的 Header 和 Manifest。

根据 Manifest 初始化更新任务，并锁定目标分区。

· 系统状态：

文件系统进入只读状态，防止写入干扰更新操作。

步骤 4：应用更新指令

· 文件变化：

对目标分区执行擦除、写入、差分更新等操作，数据源自 Data Blobs。

写入过程中会生成临时文件用于中间存储（如 /data/tmp/）。

· 分区变化：

目标分区内容被逐块替换或更新，旧版本数据被覆盖。

A/B 分区设备仅对备用分区（如 system_b）进行写入。

步骤 5：更新完成后的处理

· 文件变化：

执行 post-install 脚本，对新系统进行优化（如清理缓存、重建 Dalvik 缓存）。

更新完成后删除 /data/tmp/ 中的临时文件。

· 系统状态：

系统切换到新分区或直接重启。

4.2. A/B 分区中的分区变化

A/B 分区结构允许系统无缝升级，其变化流程如下：

4.3. 非 A/B 分区中的分区变化

在非 A/B 分区中，更新直接覆盖当前分区，流程如下：

1. 挂载目标分区（如 system）为可写模式。

2. 擦除原有数据块。

3. 写入新镜像或差分数据。

4. 校验分区内容并标记为成功。

5. OTA 升级过程的安全性

5.1. 文件验证

Android OTA 升级过程中使用多层验证机制：

1. 哈希验证：确保下载的文件与原始文件一致。

2. 数字签名：校验升级包是否由可信的密钥签名。

3. 块级校验：更新过程中逐块验证写入的数据。

5.2. 分区回滚机制

· 在 A/B 分区中，升级完成后，只有启动成功的分区会被标记为“活动分区”。

· 如果新分区启动失败，设备会自动回滚到上一个分区。

6. 总结

Android OTA 升级是一个全面且复杂的过程，其核心在于对文件和分区的操作。payload.bin 中包含了详细的分区更新指令，而 update_engine 服务负责解析和执行这些指令。通过 A/B 分区机制，升级失败的风险被大幅降低，同时支持无缝切换和自动回滚。理解这些内部细节对于排查升级问题和优化系统有重要意义。

打赏

微信扫一扫，打赏作者吧～