洛奇看世界

Android slot 槽位的切换是 Android OTA 一个比较基础的知识点，刚接触 Android OTA 的同学往往不清楚槽位 slot 到底是如何切换的，所以这也是 Android OTA 讨论群里问得比较多的问题我在[《Android A/B System OTA分析（三）主系统和bootloader的通信》](https://blog.csdn.net/guyongqiangx/article/details/72480154)有中，有做过相关内容的分析。但没有明确指出槽位是如何切换的。

经常在讨论群和答疑群看到有同学问能不能在升级时新增分区，以及如何新增分区的问题。这里打算分两篇来介绍：第一篇，介绍分区调整的基本原理。包括普通分区的增加，以及 super 设备上分区的增加；第二篇，新增分区实战。基于 Android 12(S) 代码，提供一个新增分区的实例。作为第一篇，本文从原理角度出发，详细分析分区更新的底层逻辑，让你对升级时能否增加、修改和删除分区，以及修改分区可能的风险有一个彻底的认识。

本文先单独分析 A/B 系统和 Recovery 系统各自的功能，然后对比功能差异来找到 A/B 系统并不能完全替代 Recovery 系统的原因。如果 Recovery 系统所有的功能 A/B 系统都能满足，那自然的结果就是有了 A/B 系统，就可以不需要 Recovery 系统了。如果 A/B 系统并不能实现所有的 Recovery 所具有的功能，那就无法完全替换。同时，也解释了 Recovery 系统存在的意义。

离上一系列 Android 动态分区详解有一段时间了，群里有时候有朋友抱怨说 VAB 的资料很少，VAB 学习起来有些困难；再加上一些其它因素，我最终决定继续写一写 Android 的虚拟分区系统。这一篇主要梳理一下我学习 Android 虚拟分区所用到的资料，也顺便推荐给你。主要有 3 类，Android 官方 VAB 文档，Device Mapper 文档以及 Android 代码。

上一篇《Android 虚拟分区详解(一) 参考资料推荐》提到了学习虚拟分区的一些参考资料，本篇简单说下虚拟分区的布局。说到 Android 虚拟分区布局，基本上都是直接上一张布局图就完事了，一张图就能搞定的事所以其实也没什么好说的。那为什么又要单独开篇来说呢，因为本文想在分区布局图之外说点别的，如果你很清楚各分区的布局，又能回答以下问题，那就不需要再看本文了。

到目前为止，虚拟分区前两篇分别推荐了一些参考资料，以及虚拟分区布局分析。实际上，中间为了增加对虚拟分区快照底层的理解，我又写了两篇 linux snapshot 快照的原理和实践作为参考。本文基于 Android 的官方文档关于快照和合并流程一节的内容进行介绍，试图向你解释整个升级过程中分区槽位的状态变化。

这一系列名为虚拟分区详解，到目前为止写了三篇，分别是：参考资料推荐，虚拟分区布局和分区状态变化》，中间也补充了虚拟分区底层 linux snapshot 快照的原理。从这一篇开始，逐步深入代码，从代码层面来讲解虚拟分区的代码实现。本文主要讨论一个问题，虚拟分区 VAB 的编译开关，这些开关最终都干了写什么？下篇分析 Android 虚拟分区空间的计算。

前段时间有朋友在 OTA 讨论群里说他的设备升级以后无法启动了，想要解析 metadata 分区的数据来查看整个系统升级的 merge 状态，因为他怀疑 merge 过程失败导致系统无法启动。实际上，记录系统 merge 状态的 merge status 数据不在 metadata 分区，而是在 misc 分区，这一切和 BootControl 为支持 Virtual A/B 的升级变化有关。本篇主要分析 Android R 上 BootControl HAL 接口的变化。

对于虚拟 A/B 系统来说，其虚拟的基础是 snapshot，核心是 libsnapshot 库，而 libsnapshot 中，一切操作都又交由类 SnapshotManager 处理，所以如没有搞懂 SnapshotManager 类的行为，很难说你掌握了 Android 虚拟 A/B 系统的运作方式。libsnapshot 的源码位于 system/core/fs_mgr/libsnapshot 目录下面,，本篇和接下来的几篇会详细分析 libsnapshot 代码，完成后再回到虚拟 A/B 升级

如果你在分析某个问题时，碰巧遇到了这 3 个标识文件(/metadata/ota/snapshot-boot, /metadata/ota/rollback-indicator 和 /metadata/ota/allow-forward-merge)，你都知道这些标识(indicator)文件中写了什么内容，是做什么用的吗？你知道这些文件是何时创建，何时更新，何时销毁的吗？

在虚拟 A/B 升级的过程中，假设当前运行在 A 槽位，即将升级 B 槽位的分区，因此系统需要为 B 槽位的分区(比如 system_b) 创建相应的 snapshot (快照) 设备，而创建快照时需要提供快照的 cow 文件。创建 cow 设备时，cow 所需空间会先从 super 分区的空闲空间分配，然后剩余的部分从 userdata 分区分配，并以文件的形式保存在 userdata 分区的目录下。这里先不讨论 cow 到底从哪里分配，而是讨论 cow 的大小到底是如何确定的？

上一篇《Android 虚拟 A/B 详解(八) cow 的大小是如何计算的？》详细分析了快照(snapshot)设备的后端 COW 空间所需大小是如何计算的。虚拟 A/B 在升级更新分区创建 COW 设备时，会先利用 super 设备上的空闲分区，不够的部分再从 userdata 分区(/data) 下分配文件，然后把这两部分拼接映射出 COW 设备。具体上是如何操作的呢？本文通过跟踪代码为您解开这个答案。

这是一篇临时加入的文章，计划中的第十篇并不是准备分析这个，只不过因为时常会有小伙伴在 OTA 讨论群和专栏答疑群里问如何判断一个设备是否打开了虚拟分区(Virtual A/B)功能。本文总结我知道的 5 种办法：1. 从源码判断。2. 从编译输出判断。3. 从 image 镜像文件判断。4. 从运行设备的系统属性判断。5. 从运行设备的 super 分区数据判断。

从 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。

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

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

最近突发奇想，在 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 答疑群，几经讨论，这个问题算是彻底弄清楚了。本篇专门探讨这个问题为你揭晓答案。