- OTA 全称 Over-the-Air Technology，这种在线升级，无需刷机升级的方式，叫做OTA升级，OTA升级可以借助Wifi无线网络或者手机移动网络完成升级，相当于借助空中无线网络完成升级；
- 项目中需要OTA的功能，因此有了此文，参考下Android的OTA实现机制，可以看到Android的OTA机制随着版本升级也发生了变化了，下面对此进行了总结
非 A/B 系统更新
先看下Android传统的分区结构
| bootloader：设备启动后，会先进入bootloader程序，这里会通过判断开机时的按键组合（也会有一些其他判断条件，暂不赘述）选择启动到哪种模式，这里主要有Android系统、recovery模式、fastboot模式等。 |
| boot：包含有Android系统的kernel和ramdisk。如果bootloader选择启动Android系统，则会引导启动此分区的kernel并加载ramdisk，完成内核启动。 |
| misc：主要用于Android系统和bootloader通信，使Android系统能够重启进入recovery系统并执行相应操作。 |
| system：包含有Android系统的可执行程序、库、系统服务和app等。内核启动后，会运行第一个用户态进程init，其会依据init.rc文件中的规则启动Android系统组件，这些系统组件就在system分区中。将Android系统组件启动完成后，最后会启动系统app —— launcher桌面，至此完成Android系统启动。init进程启动 |
| vendor：包含有厂商私有的可执行程序、库、系统服务和app等。可以将此分区看做是system分区的补充，厂商定制ROM的一些功能都可以放在此分区。 |
| userdata：用户存储空间。一般新买来的手机此分区几乎是空的，用户安装的app以及用户数据都是存放在此分区中。用户通过系统文件管理器访问到的手机存储（sdcard）即此分区的一部分 |
| recovery：包含recovery系统的kernel和ramdisk。如果bootloader选择启动recovery模式，则会引导启动此分区的kernel并加载ramdisk，并启动其中的init继而启动recovery程序，至此可以操作recovery模式功能（主要包括OTA升级、双清等）。 |
| cache：主要用于缓存系统升级OTA包等。双清就是指对userdata分区和cache分区的清理。 |
升级过程
- Android系统收到服务端下发的OTA推送，将OTA包下载至cache分区。
- OTA包下载完成后，将向misc分区写入指令，表明下次启动时进入recovery模式并使用该OTA包进行升级。
- 重启手机。
- 重启后最先进入bootloader，bootloader会先判断按键组合、电源寄存器等，随后会读取misc分区的内容并解析。由于步骤2中已经向misc分区写入了指令，此处bootloader读取指令后会引导启动recovery系统。
- 进入recovery，读取cache分区中的OTA包，并解析其中的升级脚本，按照其指令对系统各个分区进行升级
- recovery会清除misc分区
- 重启手机
- 重启后最先进入bootloader，判断按键组合、电源寄存器、misc分区内容等，默认情况会启动Android系统，此时已经是OTA升级后的新版本系统
缺点
- 升级下载的OTA包占用cache分区空间
- 升级失败无法恢复回旧系统
A/B系统更新
为了解决以上两个问题，在Android O之后，Google引入了一种新的分区结构，称为A/B分区，与之对应，传统分区结构被称为non-A/B分区。
A/B分区结构，顾名思义，将系统分区分成了A和B两个槽(slot)，手机启动时会选择A槽或者B槽启动，运行过程中仅使用当前槽位的分区。
采用A/B分区结构，能够实现无缝升级。例如用户正在运行A槽，此时收到OTA推送，则系统会一边从服务端获取OTA数据，一边直接写入待升级的槽，不需要临时存储OTA包的空间，因此不再需要在cache或userdata分区预留足够空间。当B槽系统升级完成，用户会收到重启提示，此时重启手机将自动切换到B槽的新版本系统。
bootloader为了判断一个系统(slot)是否为可以启动的状态，Google定义了A/B槽的几种标识：
- bootable：标识该槽的系统是否可以启动。
- successful：标识该槽的系统是否成功启动过，仅当该槽系统能够启动、运行、进行OTA升级时，才会从用户态标记该槽为successful。
- active：标识该槽是否是当前运行的系统，两个槽中只有一个能标记为active。
缺点
- 系统所需的存储空间比非A/B OTA所需的更多，因为A/B系统的分区boot. system, vendor等都作了两套分区
虚拟A/B
为了解决上面的问题，Android在后面新增了虚拟A/B系统更新；
- 对于AB分区，就是传统的备份，也就是system_b就是system_a的副本；而对于virtualAB，用的就是写时复制快照技术，所以这些动态分区无需AB，有修改就创建快照，下次启动如果成功，就说明对于分区的修改没有问题，就将快照和原本的base合并，作为最新的base
- virtualAB备份的不是副本，而是快照。节省空间。
动态分区
动态分区解决的是各个分区映像不再需要预留空间。借助动态分区，供应商无需担心各个分区（例如 system、vendor 和product）的大小。取而代之的是，设备会分配一个super 分区，其中的子分区可动态调整大小。
动态分区是使用Linux内核中的dm-linear device-mapper模块实现的。在Android Q上，对system分区的访问被驱动拦截并转发为对super分区某个区域的访问。类似于做一个映射关系。
Snapshot
比如，我有一串数据“ABCDEF”，存储的地址是从0x0到0x5，备份就是我找一块空间0x7到0x12，我把数据完全的拷贝到这块空间，从这里看备份的缺点很明显，如果数据比较大，但改动又不多或者集中在某个区域，就很占用空间，而且比如我就1000位数据我常改其中50位的数据，你就都备份，那有浪费了950位数据的额空间。而快照技术并不备份所有数据，我只记录上次对这部分数据进行写操作的时间点和改动的数据（不是全部数据），这样我要记录的数据比起把数据全部备份就少的多了。
快照里的一种实现方式就是写时复制；就是比如我要把“ABCDEF”这串数据（存储的地址是从0x0到0x5）改为“ABCMEF”，只把其中的D改为M，就是我先把元数据读出来（从0x3读出D），然后把D改成M，然后改动的数据写在另一个位置（快照），然后再把改动的数据写到元数据处（0x3）
流程
- 先创建system_b_base，对应映射到system_a；
- 创建sytem_cow(copy-on-wirte 写时复制)(可能由超级分区中的空闲块组成，也可能是/data上分配的块上的循环设备，或者两者都有)
- base和cow统一组成一个快照
- 当设备在应用更新后重新引导时，发现有快照，系统就从快照上进行挂载，直到成功引导。从快照挂载成功后，把base和快照的内容合并。这样就可以删除快照设备了
小结
