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系统更新；

扫描二维码关注公众号，回复： 15882284 查看本文章

对于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和快照的内容合并。这样就可以删除快照设备了

浅析Android OTA机制