OTA和Recovery系统升级流程介绍
本文介绍了Android原生OTA和Recovery升级过程步骤.
进入升级
- 1.1 正常启动和进入Recovery的区别
下面给出了升级流程的简单示意图。
上图中的上下两个部分,上面一部分是正常的启动模式,下面一部分为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
- 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文件来实现的,涉及到的文件如下表。
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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
Command:重启进入recovery或者是更新radio或Bootloader硬件时,会更新这个域;
Status:在bootloader完成“update-radio”和”update-hboot”命令之后更新;
Recovery:用于system和recovery之间的通信;
Stage:需要重启多次的packages会写入这个值,表示所处的状态。
上面的过程可以总结为如下的示意图:
cache/recovery/command中command有哪些?
下表给出一些常用的命令和其含义。
- 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;
OTA安装
- 4.1 OTA简介
OTA,即Over the air,它可以实现完整的版本升级,也可以是增量升级。用户可以选择在SD卡中作本地升级,也可以直接采用网络在线升级。不管是哪种方式,都有几个过程:生成升级包、获取升级包、执行升级包,生成升级包不做介绍,。
实际上,所谓OTA的整个过程可以用如下示意图表示。
首先,用户用手机的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++改写了一遍,官方文档两者改写的函数进行了对比
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脚本中的命令并执行
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
- 1
- 2
- 3
- 4
- 5
- 6
常用的Updater-script命令
OTA和Recovery系统升级流程介绍相关推荐
- Recovery系统升级(3)---软件流程
系统升级软件流程 本章节结合源码剖析Recovery系统升级流程,流程中相关技术难点或者细节会单独文章介绍,文中相应位置会附上链接. 从APP检测到服务器推送OTA升级包到设备启动到新版本系统的整个软 ...
- 【android系统】android系统升级流程分析(一)---recovery模式中进行update包升级流程分析
今天我们直接来看下android中具体的升级过程是如何的. 升级流程概述 升级的流程图: 升级流程分析 第一步:升级包获取 升级获取可以通过远程下载,也可直接拷贝到指定目录即可. 第二步:准备升级 然 ...
- OTA常见方案分析(差分升级 全量升级 AB面升级 Recovery系统升级)
1.全量升级: 完整的下载新版本固件,下载完成后将固件搬运到APP程序运行的位置.(一般来说是将APP从片外flash搬运到片内flash上).搬运完成后校验通过后重启APP. 2.差分升级: ...
- Android OTA升级原理和流程分析(五)---update.zip包从上层进入Recovery服务
转载自:http://blog.chinaunix.net/uid-22028566-id-3533854.html 文章开头我们就提到update.zip包来源有两种: 一个是OTA在线下载(一般下 ...
- 【android系统】android系统升级流程分析(二)---update升级包分析
接下来我们将通过几篇文章来分析update.zip包在具体Android系统升级的过程,来理解Android系统中Recovery模式服务的工作原理.今天让我先来分析下升级包update.zip. 一 ...
- Android OTA升级原理 - 实现流程(整理一)
Android OTA实现流程分析 OTA升级概述 制作升级包 自动生成update.zip升级包 手动生成update升级包 增量包目录结构 升级包写入设备分区 Android的三种工作模式 Rec ...
- android ota升级涉及的分区,Android OTA升级原理 - 实现流程(整理一)
Android OTA实现流程分析 OTA升级概述 制作升级包 自动生成update.zip升级包 手动生成update升级包 增量包目录结构 升级包写入设备分区 Android的三种工作模式 Rec ...
- Android原生OTA和Recovery升级过程步骤
本文介绍了Android原生OTA和Recovery升级过程步骤. 进入升级 - 1.1 正常启动和进入Recovery的区别 下面给出了升级流程的简单示意图. 上图中的上下两个部分,上面一部分是正常 ...
- 聊天机器人之需求分析和流程介绍
聊天机器人之需求分析和流程介绍 1. 需求分析 在黑马头条的小智同学板块实现聊天机器人,能够起到智能客服的效果,能够为使用app的用户解决基础的问题,而不用额外的人力. 但是由于语料的限制,所以这里使 ...
最新文章
- win10 anaconda 下pcl库的安装
- Art Generation with Neural Style Transfer-v2
- 关于datagrid中控件利用js调用后台方法事件的问题
- JSP 和 Servlet 区别
- JS~~~ 前端开发一些常用技巧 模块化结构 命名空间处理 奇技淫巧!!!!!!...
- 4.线性和卷积——线性滤波器、非锐化掩蔽原理揭破_4
- 在pycharm运行正常,在命令行窗口出现引包错误
- 数据库SQL语言从入门到精通--Part 1--SQL语言概述
- Photoshop/PS中如何写维吾尔语等语言 乱码
- mysql max connects_出现mysql max-connections问题解决解决办法
- 计算机word基础操作知识点,计算机WORD知识点整理
- 信息系统项目管理师2019年上半年上午试题解析(四)
- 实验四实验四实验四啊!
- php java rsa_java和php实现RSA加密互通-b
- 更改sqlserver服务器的登录名称
- DBCO-MMPs-PEG DBCO-基质金属蛋白酶MMPs-聚乙二醇
- informa医药数据库价格
- 文献阅读01-空间众包-最大化任务分配数量
- USB限流IC,限流开关保护芯片
- kong笔记——kong的权限认证插件选择参考
热门文章
- wpf 动画_WPF中监视动画进度
- mapper中 <include refid=“XXX“></include>标签 <sql id=“XXX“>标签
- java最长回文子序列_LeetCode[5] - 最长回文子串动态规划
- windoes硬盘备份(数据迁移)的方法
- ValueAnimator API 介绍
- 办公软件Office 2010下载安装介绍
- 向量距离计算 java_Milvus 向量搜索引擎开源了!
- Hadoop详解(六):MapReduce计算框架详解
- 10没有基于策略的qos_基于强化学习的用户移动场景下空中基站3D位置高效部署...
- 没有可用于当前位置的源代码