OTA和Recovery系统升级流程介绍

刺骨的言语ヽ痛彻心扉 2023-02-27 05:54 472阅读 0赞

本文介绍了Android原生OTA和Recovery升级过程步骤.

## 进入升级 ##

**- 1.1 正常启动和进入Recovery的区别**

下面给出了升级流程的简单示意图。  
![这里写图片描述][20160125150119871]  
上图中的上下两个部分，上面一部分是正常的启动模式，下面一部分为Recovery模式。正常的启动模式是从boot.img启动系统（Main System），而recovery模式则是从reovery.img启动系统；（reovery.img只包含内核、简单的文件管理系统和图形系统）

Boot分区包括linux内核和Ramdisk，Recovery分区也包括Linux内核和Ramdisk，一般来说内核是一样的，但Ramdisk区别则非常大，recovery中的ramdisk会有更多的recovery需要使用的程序和数据。

**- 1.2 分区介绍**

这里说到的boot.img和recovery.img，其实就对应了一个Android设备中的分区，一般来说，android设备会包含以下几个分区

**Boot**：包含Linux内核和一个最小的root文件系统（装载到RAM disk中），用于挂载系统和其他的分区，并开始Runtime  
**System**：包括了系统应用和库文件（AOSP中可以获取到源代码），在运行的过程中，这个分区是read-only的，只有在OTA升级的时候才会发生变化  
**Vendor**：包括了系统应用和库文件（AOSP中不能获取到源代码），和System分区一样，只有在OTA升级的时候才会发生变化  
**Userdata**：用户安装的应用程序会把数据保存在这里，正常情况下OTA是不会清除这里的数据的，指定要删除出具的除外  
**Cache**：临时的保存应用数据（要把数据保存在这里，需要特地的app permission）,OTA的升级包也可以保存在这里。OTA升级过程可能会清楚这个分区的数据。  
**Recovery**：包括了一个完整Linux内核和一些特殊的recovery binary，可以读取升级文件用这些文件来更新其他的分区  
**Misc**：一个非常小的分区，recovery用这个分区来保存一些关于升级的信息，应对升级过程中的设备掉电重启的状况

这些分区是Google官方的标准，实际的情况可能不太一样，就Find 7而言，刷机包里面的分区只有以下几个 ：芯片厂商和手机厂商会根据自己的需要加一些其他的分区，如下面的persist.img是高通的，reserve4是我们自己加的保留分区，MTK还有preloader、lk，高通的还有NON-HLOS.bin、sbl、emms\_aboot等。

## Bootloader ##

**- 2.1 什么是Bootloader?**  
在嵌入式操作系统中，Bootloader在操作系统内核运行之前运行，可以初始化硬件设备、建立内存空间映射图，为调用操作系统内核准备好正确的环境。Bootloader和硬件是强相关的，且厂商一般都会对bootloader加锁，这样就不能随便刷机了。  
当然bootloader也是可以解锁的，这里不得不提一下root和bootloader解锁分别是怎么一回事：root是通过内核漏洞获取最高的权限，也就是所谓的超级用户（su,superuser），属于系统层面，root之后就可以修改system分区的数据；bootloader解锁则属于硬件层面的解锁boot和recovery分区，解锁bootloader不会root手机。更多见参考文献\[1\].

**- 2.2 Fastboot和recovery的区别？**  
Bootloader过程中，先做一些初始化，然后根据组合键做不同的事情，这个过程内核没有加载，机器知识在按顺序执行指令。  
Fastboot：在这种模式下，可以修改手机的硬件，并且允许我们发送一些命令给Bootloader。如使用电脑刷机，则需要进入fastboot模式，通过电脑执行命令将系统镜像刷到通过USB刷到手机中。  
Recovery：Recovery是一个小型的操作系统，并且会加载部分文件系统，这样才能从sdcard中读取升级包。  
Bootloader.cpp  
Bootloader（bootable/recovery/bootloader.cpp）会读取位于MISC分区的启动控制信息块BCB（Bootloader Control Block），通过函数

int get_bootloader_message(struct bootloader_message *out);
    int set_bootloader_message(const struct bootloader_message *in);

*  1
 *  2

如果command的值为“boot-recovery”时，就进入recovery模式。Recovery升级过程中掉电，下次按power键开机也会进入recovery模式就是因为misc分区依然存在recovery信息（掉电保护）。

## Recovery模式 ##

**- 3.1 Recovery、Bootloader以及Main System通信方法**  
图1中给出模式比较简单，实际上三个实体的交互过程并不是图1那种单向的顺序流程，而是一个双向的流程，于是就涉及到个三个部分的通信方法的实现。  
**Recovery和Main System交互**  
这一部分源代码（bootable/recovery/recovery.cpp）注释中有详细的介绍，这里大致总结一下：这两个部分交互是通过/cache文件来实现的，涉及到的文件如下表。  
![这里写图片描述][20160125150636451]  
**Recovery、Main System和Bootloader交互**  
这个交互过程是通过BCB来完成的，BCB其实就是一个struct（在misc分区），在（bootable/recovery/bootloader.h）中定义。

struct bootloader_message {
        char command[32];//command存储在这个field里面
        char status[32];
        char recovery[768];
        char stage[32];
        char reserved[224];
    };

*  1
 *  2
 *  3
 *  4
 *  5
 *  6
 *  7

Command：重启进入recovery或者是更新radio或Bootloader硬件时，会更新这个域；  
Status：在bootloader完成“update-radio”和”update-hboot”命令之后更新；  
Recovery:用于system和recovery之间的通信；  
Stage：需要重启多次的packages会写入这个值，表示所处的状态。  
上面的过程可以总结为如下的示意图：  
![这里写图片描述][20160125150737061]

**cache/recovery/command中command有哪些？**  
下表给出一些常用的命令和其含义。  
![这里写图片描述][20160125150827734]

**- 3.3 Factory Reset—恢复出厂设置**  
恢复出厂设置也在recovery.cpp中完成，具体的流程如下：  
1) 用户选择恢复出厂设置  
2) Main System会在cache/recovery/command中写入—wipe-data的命令，然后重启进入recovery  
3) 通过get\_args在BCB中写入boot-recovery和wipe-data命令  
4) 然后重启进行erase\_volume  
5) 擦除数据之后调用finish\_recovery将BCB中的数据清除  
6) main()函数调用reboot()进入Main System;  
![这里写图片描述][20160125150937124]

## OTA安装 ##

*  **4.1 OTA简介**

OTA，即Over the air，它可以实现完整的版本升级，也可以是增量升级。用户可以选择在SD卡中作本地升级，也可以直接采用网络在线升级。不管是哪种方式，都有几个过程：生成升级包、获取升级包、执行升级包，生成升级包不做介绍，。  
实际上，所谓OTA的整个过程可以用如下示意图表示。  
![这里写图片描述][20160125151037797]  
首先，用户用手机的OTA检查更新（或者是自动更新），发送查询数据给服务器，然后服务器查询到相应的包，并返回下载地址给OTA.apk，然后OTA.apk进行下载，把下载的数据存储在手机的某个分区。完成之后用于选择是否升级，升级的时候OTA会发送命令给Main System，进入recovery，recovery根据利用下载下来的升级包完成升级过程。  
从图中，我们可以看出OTA.apk实际上只是完成了从服务下下载安装包，以及发送升级命令，功能似乎很容易描述，但是实际上要做的事情却是非常多的，特别是OTA 2.0将Applypatch功能移植到OTA.apk之后，复杂度进一步增加了。

*  **4.2 OTA安装流程**
    
    下面对Recovery的升级步骤做一个梳理：  
    1) Main System下载OTA升级包，官方推荐下载到/cache分区下，但是实际上可以自己选择存储地方；  
    2) Main System在/cache/recovery/command中写入“—update\_package=安装包路径”  
    3) 系统重启进入recovery，这一步是通过PowerManager的reboot(“recovery”)实现的  
    4) Get\_args()在BCB中写入“boot-recovery”和”—update\_package“，这样就保证了即便是设备出故障重启了，只有这两个命令还在，就会尝试重新安装OTA升级包  
    5) Install\_package尝试开始安装OTA升级包  
    6) Finish\_package擦除BCB  
    7) 如果升级失败  
    Prompt\_and\_wait显示错误，并等待用户响应  
    用户重启  
    8) 设备重启进入MainSystem  
    此外，还有个maybe\_install\_firmware\_upadate，具体过程不做介绍了。

下面是Recovery的代码的区别，实际上2.3/3.0/4.4和5.0的代码差别还是非常大的，原因是5.0的recovery用C++改写了一遍，官方文档两者改写的函数进行了对比  
![这里写图片描述][20160125151134863]  
![这里写图片描述][20160125151201567]

![这里写图片描述][20160125151259161]

*  **4.3 Install\_package过程**
    
    安装过程在/bootable/recovery/install.cpp中，  
    install\_package(const char\* path, int\* wipe\_cache, const char\* install\_file, bool needs\_mount)  
    在recovery的main函数中传入的参数如下：  
    install\_package(update\_package, &wipe\_cache, TEMPORARY\_INSTALL\_FILE, true);  
    参数列表：  
    \-Path：传入的安装包地址  
    \-wipe\_cache：是否擦除cache分区  
    \-install\_file：实际上是安装过程的临时安装文件的地址（/tmp/last\_install），包括install\_log  
    \-needs\_mount：是否需要Mount，安装过程传入的是true  
    在install\_package函数中，其实真正调用的是really\_install\_package函数:  
    result = really\_install\_package(path, wipe\_cache, needs\_mount);  
    这里对几个重要的流程做一些介绍：  
    \-Set\_install\_mounts：检查安装包所在路径的分区是否挂载，否则返回安装失败  
    \-Set\_backgroud：升级过程的UI界面显示  
    \-Load\_keys，加载公钥，我们系统的签名文件放在/build/target/product/security/目录下。这样做的目的是为了防止用户使用不同的项目的升级包进行混刷，导致刷机变砖的情况；  
    \-verify\_file()：对升级包update.zip包进行签名验证；  
    \-mzOpenZipArchive()：打开升级包，并将相关的信息拷贝到一个临时的ZipArchinve变量中。这一步并未对我们的update.zip包解压。  
    \-try\_update\_binary()：在这个函数中才是对我们的update.zip升级的地方。这个函数一开始先根据我们上一步获得的zip包信息，以及升级包的绝对路径将update\_binary文件拷贝到内存文件系统的/tmp/update\_binary中  
    \-execv(binary,args)的作用就是去执行binary程序，这个程序的实质就是去解析update.zip包中的updater-script脚本中的命令并执行  
    ![这里写图片描述][20160125151442033]
 *  **4.4 Update-binary和Updater-script**

上面，我们讲到execv执行二进制文件和Updater-script脚本中的命令，这两个文件在下面的目录。Apply\_patch过程其实是会预先在APK端提取出来这两个文件的。  
try\_update\_binary运行时，会首先从安装包中读取出update-binary这个可执行文件。创建一个管道(作用稍后会讲到)，并在一个新线程中运行这个update-binary(即updater，主函数见bootable/recovery/updater/updater.c)，update-binary运行的时候，先会从升级包中读取update-script。  
bootable/recovery/updater/updater.c中会注册函数，而这些被注册的函数在updater-script中有使用到。

// Configure edify's functions.
        RegisterBuiltins();
        RegisterInstallFunctions();
        RegisterBlockImageFunctions();
        RegisterDeviceExtensions();
        FinishRegistration();

*  1
 *  2
 *  3
 *  4
 *  5
 *  6

常用的Updater-script命令  
![这里写图片描述][20160125151550783]

[20160125150119871]: /images/20230209/da4227ade37b4cc8a34d539813fa7010.png
[20160125150636451]: https://img-blog.csdn.net/20160125150636451
[20160125150737061]: https://img-blog.csdn.net/20160125150737061
[20160125150827734]: /images/20230209/8cd4905002f34340a0999eca506bd579.png
[20160125150937124]: /images/20230209/85e5f41d38534899b9903a9f193a5d49.png
[20160125151037797]: /images/20230209/2db604a3af8c41ab84bac1c69d448fab.png
[20160125151134863]: /images/20230209/fc4777676fb040d59d02fe4e5e6d705f.png
[20160125151201567]: /images/20230209/f03cefd5df9e4e338bb0440f7d8ddd36.png
[20160125151259161]: /images/20230209/6f131f73300b414482810a2c22b6dc62.png
[20160125151442033]: /images/20230209/991d86dd4db84f3fa42b9c1f3f78a6c0.png
[20160125151550783]: /images/20230209/977f86d447a9482e8dc2a7ce7d0a35fa.png