洛奇看世界

从 Android Q 引入动态分区，到 Android R/S 在动态分区之上增加虚拟分区管理, OTA 升级时需要对分区变更进行处理，不了解动态分区就无法深入 Android OTA 升级。因此最近花了些时间阅读代码，学习 Android 动态分区。本篇主要讲述动态分区的核心数据结构以及动态分区的生成和映射流程。

上一篇提到 Android 动态分区的核心是位于 super 分区头部 4K 偏移处开始的 metadata 数据，本篇简单介绍动态分区核心的代码模块和相关工具

官方页面从比较高的角度综述了 Android 动态分区，包括基本原理，配置说明，注意事项等，目的还是给大家介绍如何使用动态分区，重点不在于强调原理。本文根据设备是否存在 super 分区，将包含 super 分区的称为原生动态分区，对应于 Android 的默认动态分区配置；将从低版本升级上来不包含 super 分区的称为改造动态分区，对应于 retrofit 的配置。本文重点介绍 Android 动态分区的这编译配置，这些配置是如何生效，super.img 又是如何生成的。

动态分区机制的底层由 linux 的 device mapper 驱动实现。因此，Android 的动态分区，主要强调的是 linux 驱动之上，Android 对动态分区的管理。第一篇《Android 动态分区详解(一) 5 张图让你搞懂动态分区原理》中提到过我对 Android 动态分区本质的看法: 动态分区管理的本质就是对分区数据的增删改查操作，操作的数据对象就是动态分区描述数据 metadata。

本文作为《Android 动态分区详解(一) 5 张图让你搞懂动态分区原理》 的补充，进一步解释 device mapper，dm-linear 以及动态分区。并通过 3 个实验来加强对 linear 设备以及 Android 动态分区的理解。

主要介绍动态分区生成 super.img 的两个隐藏开关。如果你配置了动态分区，结果编译时却没有生成 super.img，本文值得一看，否则不需要看本文。

最近突发奇想，在 OTA 讨论群里搜索一下 remount 相关的聊天记录，这个问题引起的话题实在是太多了，所以是时候觉得有必要详细说明 overlay 和 remount 这个问题了。本文从 overlay 文件系统的基本原理出发，简单介绍了 Linux 和 Android 系统中的 overlay 文件系统及相关内容，重点在 Android 中的 remount 操作会从 super 设备或 data 分区分配空间用于 overlay 文件系统。如果只对结论感兴趣，请直接跳转到第 6 节。

写完《Android AB System OTA分析》系列后打算一口气将Update Engine也写了的，但一直由于各种借口，最终没有完成。后来6月份的时候陆陆续续读了Update Engine部分代码，记了点笔记，本打算等彻底读完再分享的，但按照目前的进度不知道读完是哪一天，所以先将笔记贴在这里，如果我的这几篇笔记能对您阅读或理解Update Engine机制有一丝帮助，那花时间整理也是值得的...

Android Update Engine分析（二）Protobuf和AIDL文件 技术文章直入主题，展示结论，容易让人知其然，不知其所以然。 我个人更喜欢在文章中展示如何阅读代码，逐步分析解决问题的思路和过程。这样的思考比知道结论更重要，希望我的分析能让你有所收获。1. Update Engine中的特殊源文件在上一篇《Android Update Engine分析（...

Android Update Engine分析（三）客户端update_engine_client 技术文章直入主题，展示结论，容易让人知其然，不知其所以然。 我个人更喜欢在文章中展示如何阅读代码，逐步分析解决问题的思路和过程。这样的思考比知道结论更重要，希望我的分析能让你有所收获。前面两篇分别分析了Makefile，Protobuf和AIDL相关文件，从本篇开始正式深入功能实...

Android Update Engine分析（四）服务端进程前面三篇分别分析了Makefile，Protobuf和AIDL相关文件以及Update Engine的客户端进程update_engine_client，Android Update Engine分析（一）MakefileAndroid Update Engine分析（二）Protobuf和AIDL文件Android Up...

Android Update Engine分析（五）服务端核心之Action机制前面四篇分别分析了Makefile，Protobuf和AIDL相关文件, Update Engine的客户端进程update_engine_client以及Update Engine的服务端:Android Update Engine分析（一）MakefileAndroid Update Engine分析（...

Android Update Engine分析（六）服务端核心之Action详解本系列到现在为止的前五篇分别分析了Makefile，Protobuf和AIDL相关文件, Update Engine的客户端进程，Update Engine的服务端及Action机制:Android Update Engine分析（一）MakefileAndroid Update Engine分析（二）Pr...

Android Update Engine分析（七） DownloadAction之FileWriter本系列到现在为止的共有六篇，分别分析分析了Makefile，Update Engine的客户端、服务端及Action机制的细节:Android Update Engine分析（一）MakefileAndroid Update Engine分析（二）Protobuf和AIDL文件Andr......

Android Update Engine分析（八）升级包制作脚本分析本系列到现在为止共有七篇，分别如下:Android Update Engine分析（一）MakefileAndroid Update Engine分析（二）Protobuf和AIDL文件Android Update Engine分析（三）客户端进程Android Update Engine分析（四）服务端进程And...

最初计划《Android Update Engine分析》系列的时候，大概有十二篇左右，后来分析 payload 数据生成时觉得要花很多时间去分析整理和消化，就放了一放，结果这一放，3 年就过去了，时间真是过得很快。中间不少朋友加我微信询问 delta 数据生成的问题，也只能不了了之。最近决定继续这一系列的写作。计划中的后续内容包括 payload 生成的所有细节，以及 update engine 从 Android N 开始的演化，动态逻辑分区等。

本篇从代码上一步一步分析生成 payload 和 metadata 数据的哈希值的逻辑流程。如果只想看整个函数调用总结，请转到第 3 节，如果想在 linux 命令行通过手工计算来验证，请跳转到第 4 节。

上一篇《Android Update Engine 分析（十）生成 payload 和 metadata 的哈希》详细分析了 metadata 和 payload 的哈希时如何生成的，本篇继续分析脚本中是如何对这两个哈希进行签名，并将签名结果更新到 payload 文件中。

上两篇详细分析了 metadata 和 payload 的哈希如何生成，如何签名，如何更新到 payload 文件中，本篇继续分析代码是如何验证 payload 签名的，包括代码中验证签名的流程和签名在命令行的手动验证。本篇主要内容有三点：1. 如何提供公钥和验证签名；2. 总结 payload 的处理流程；3. 手动在命令行提取 payload 的数据进行验证。

前面三篇分别分析了，如何生成 payload 的哈希，如何对 payload 的哈希签名，如何将 payload 的签名写回 payload 文件中。本篇分析如何提取 payload 文件的属性数据，包括 payload 的 "`FILE_SIZE`" 和 "`FILE_HASH`"，以及 metadata 数据的 "`METADATA_SIZE`" 和 "`METADATA_HASH`"。

生成 payload 数据是 `delta_generator` 工具最主要的功能，当我准备重新更新这一些列文章时，一开始就想写这个的，不过因为太久没看，不记得 payload 细节了，更无从从细节上分析。所以就先写一些简单的操作，等熟悉了再开始写。经过前面篇的分析了解 payload 结构，现在是时候来解决这个问题了。

生成 payload 时，会选择不同的策略去遍历每一个分区的每一个 block 生成相应的 Operation 数据:1. 差分升级的情况下，如果 version.minor = 1, 则使用 InplaceGenerator 策略2. 差分升级的情况下，其它情况使用 ABGenerator 策略3. 全量升级情况, 使用 FullUpdateGenerator 策略 本篇分析最简单的 FullUpdateGenerator 策略

上一篇《Android Update Engine 分析（十五） FullUpdateGenerator 策略》详细分析了制作全量包使用的 FullUpdateGenerator 策略，本篇详细分析制作差分包使用的 ABGenerator 策略，虽然说叫详细分析，但因为涉及代码多，层次深，这里主要捡一些重要函数进行注释，其它略过。

Update Engine 在升级时，最底层的操作就是一个个的 InstallOperation, 根据 InstallOperation 的 Type 和 data, 在源分区和目标分区执行相应的操作，最终在目标分区得到期望的数据。在本篇中，我们不用去管升级的各种流程, 各种签名，只关注 InstallOperation 的 10 种 Type 对应的数据时如何生成的，又是如何使用的。

过去一直以来陆续有朋友问，差分数据到底是如何更新的？其实我一开始在这个问题上也犯了错误，没搞清楚整个分区更新流程。本文详细跟踪差分数据接收到以后，manifest 数据时如何被解析和使用，InstallOperation 数据又是如何被用于更新的。

说来惭愧，几年前，我把 Android 的 system/update_engine 目录下早期的代码翻了一遍，很多地方提到了并且使用了 extent 这个概念来处理数据，但我一直没有搞懂 extent 到底是个什么东西，只是知道一个 extent 由两个数据表示，一个表示起始位置，另一个表示长度。在制作升级包时，差分操作基于 extent 进行；在设备端升级时基于 extent 进行还原。仅致于此，并没有继续深究~最近才了解到 extent 是现在常见的文件系统组织方式，突然一惊，真是 out 了

时不时有同学在 OTA 讨论群和 VIP 答疑群问升级速度的问题，其中一个典型的问题是：为什么差分包比全量包小，但升级时间却更长？与几百 M 甚至几个 G 的全量包相比，差分包相对较小，有时候甚至小到只有几个 M，这么小的差分包，意味携带的 payload 数据很少，写入很少的数据耗时应该很少才是。但为什么现实中差分升级时，差分包很小，但升级时间却比大很多的全量包升级更长。前段时间又有类似话题出现在 VIP 答疑群，几经讨论，这个问题算是彻底弄清楚了。本篇专门探讨这个问题为你揭晓答案。

我的第一篇 A/B 系统分析文章《Android A/B System OTA分析（一）概览》从总体上介绍了什么是 A/B 系统，A/B 系统如何进行升级切换，应该是不少人 A/B 系统升级的入门读物。从那之后，我陆续写过几十篇 Android A/B 系统升级的文章(到现在也还有很多话题没有写)，但每一篇都只分析了很小的一部分，要不就是分析功能代码，要不就是分析处理流程，要不就是演示工具使用。似乎从来没有一篇从总体角度上，全面又很详细介绍 Android A/B 系统升级。幸运的是，Android 官方对

在我的 OTA 讨论群以及 VIP 答疑群里每隔一段时间就会有人问关于 OTA 降级，以及升级时检查 max_timestamp 失败的问题。我觉得有必要把这个问题总结一下。因此，本篇详细分析 OTA 升级时检查 max_timestamp 失败的原因，以及 max_timestamp 的整个处理流程。

在 OTA 讨论群呆久了，经常就能听到各种需求。最常见的一个就是升级后清除用户数据。对老同学们来说这个问题非常非常简单；但对不了解 OTA 的新同学来说，这可能有点无从下手。如何在升级后清除用户数据？一句话，在制作升级包时指定 “–wipe-user-data” 选项就可以了。今天单独写一篇关于升级后如何清除用户数据的话题，其实主要不是为了介绍怎么做，而是梳理一下清除用户数据的流程，包括从制作升级包开始，到最终用户数据被清除的这一整个过程。

Android 中，跟降级相关的选项比较多，在 Android 13 的代码中就包含了以下这些选项：downgrade，override_timestamp，vabc_downgrade，spl_downgrade。后续会逐个场景展开分析，本篇主要分析使用 `–downgrade`制作降级包的场景。读完本文，你将得到以下问题的答案：升级或降级的本质是什么？我们制作降级包时到底发生了什么？使用降级包进行 OTA 更新时又发生了什么？

本系列到现在为止一共二十四篇，前面十七篇基本上就是阅读 update engine 的核心代码和函数，第十七篇以后开始按照话题进行分析。在前面十七篇中，把核心功能代码过了一遍，但仍然有不少功能代码还没分析过。例如，Update Engine 的升级状态数据时如何保存的？系统到底定义了哪些 prefs 数据？本文就管理 Update Engine 状态的 Prefs 类进行详细分析。

上一篇《Android Update Engine分析（二十五）升级状态 prefs 是如何保存的？》 主要分析了 Update Engine 中 prefs 的实现，以及对所有使用 prefs 的统计。在最后打算以 kPrefsBootId 为例，提供一些研究 prefs 的方法。但随着学习的深入，发现 kPrefsBootId 的变化涉的内容很多。这个过程包括，系统升级，成功更新各分区镜像，接着写入 prefs 状态标记，设备重启，系统启动 Update Engine 服务进程，Update Engin

上篇《Android Update Engine分析（二十六）OTA 更新后不切换 Slot 会怎样？》 分析了 OTA 更新但如果不进行切换，重启会失败的原因，以及我的一种解决思路。分享到 OTA 答疑群后，小伙伴子非鱼分享了他的理解，比我提到的方法更简单，立马打脸了(也不完全算是打脸，主要是现成的，更简单直接，在这里也特别对子非鱼的分享表示感谢)。哈哈，我欢迎这样打脸，大家多交流才有进步。简而言之，如果我们升级以后，又不希望切换 Slot，就可以借用 "SWITCH_SLOT_ON_REBOOT=0"

之前 Android OTA 交流群里有人问过，说他的升级包太大，有什么办法可以调整升级包的大小，其中一种尝试的方式就是进行压缩。碰巧前段时间群里又有人发起话题，想知道 payload.bin 是不是一个压缩文件，估计是他的 payload.bin 文件太大了，希望能够压缩一下。简单来说，payload.bin 并不是一个压缩文件，但里面的数据大部分已经充分压缩过了，所以整个文件也就没有多少可以再压缩的空间了。

关于如何连续进行多个版本升级，这是一个很常见的需求，也是 OTA 讨论群里试不试就会讨论的一个话题。这个场景一般来自测试对多版本连续升级的检查需求：当前系统运行在 A 槽位(版本 v1)，然后希望对 B 槽位进行连续多个版本的升级。以升级两个版本 v2, v3 为例，希望先将 B 槽位升级到版本 v2，然后保持系统运行在 A 槽位，继续将 B 槽位版本从 v2 升级到 v3。这个场景看起来很合理，但实际上没有必要。