摘要
本文首先介绍了Android系统更新要用到的一些概念:硬件、三种模式及相互之间的通信。然后介绍了Android系统的启动和升级流程。
概述
通常,Android系统的升级包名称为update.zip。Android系统内部自带了烧写升级包的工具,我们可以手动烧写,也可以通过某些机制自动更新系统。同时,我们可以手动修改和制作升级包。本文主要阐述在Android系统升级中用到的一些概念,本文只是作为索引,并不涉及到具体的烧写工作。本文基于Android系统的版本:4.0.4。
硬件
Android系统的烧写,是非常贴近硬件的。一是,烧写是在实实在在的硬件上操作的。二则,有时在翻阅源码的时候,需要知道硬件的类型,以便找到和硬件相对应的源码。
烧写相关的硬件主要有三部分:CPU、内存和nand flash。当然,只是相对本文而言。CPU用来执行程序中的指令。内存只是在运行中,将需要运行的程序加载其中并运行,关机后即消失。nand flash用来存储程序的数据,它会一直存在。系统启动时,会将nand flash上的操作系统加载到内存,然后运行在CPU中,对于非系统程序,按需加载到内存中运行。了解这些,有助于了解整个烧写的过程。
在板子上,可以通过下面的命令,查看CPU的信息:
cat /proc/cpuinfo
通过如下命令查看内存的信息:
cat /proc/meminfo
nand flash是需要分区的,每个分区中对应了Android系统烧写包中不同的image,比如:boot、system分区等。可以通过如下命令来查看nand flash的分区情况:
cat /proc/mtd # 查看分区状况
通常,nand flash包含了以下分区:
- 开机动画:用于在开机或者升级过程中显示在屏幕上的内容。
- boot:用于Android系统的正常启动
- recovery:用于Android系统进入recovery模式下,参见本文后续介绍。
- misc:用于保存BCB的内容,参见本文后续介绍。
- system:对应于Android系统的正常模式下的/system目录。
- cache:用于不同模式之间的通信,参见本文后续介绍。
- user-data:用于Android应用数据的存放。
通过下面的命令查看nand flash的总大小:
dmesg | grep NAND
三种模式
烧写的过程中,需要在三种模式下互相切换。确切的说,应该是三个操作环境:bootloader、recovery和main system。
bootloader主要用来屏蔽硬件的差异,类似于PC中的BIOS,它的功能相对比较简单,内部提供了一些命令,比如:可以将nand flash分区加载到内存、运行内存中的程序、操作SD卡等。Android中的booloader是uboot,位于源码的uboot目录下。
main system就是正常运行的Android操作系统,而recovery则是一个mini的Android系统,顾名思义,就是用来进行系统恢复相关的操作的,它的运行规则和main system一样,只是,它在启动时只加载recovery服务,此服务用于烧写Android系统。
三者之间的关系如下图所示:
系统先启动到bootloader模式下,然后根据情况,启动到recovery或者main system模式下。
bootloader
板子启动时,在Putty控制台中按回车,可以进入uboot,输入help可以查看其可用的命令。uboot的命令是可以自定义的,需要在uboot源码中进行设置。uboot下可以使用fastboot命令,进入fastboot模式下,可以使用PC与之连接(此时,使用fastboot协议通信),进行Android系统的烧写工作。
在uboot中,你可以更新uboot在内的所有系统模块。
recovery
recovery系统包含了内核和类似于根文件系统两部分,启动时仍采用init进程和init.rc配置脚本,不同的是init.rc脚本比较简单,system目录中只存放了一些必备的工具。
recovery系统下,你能更新除uboot之外的所有Android系统模块。
recovery模式下,只有一个recovery服务,该服务对应于recovery进程,源码位置:bootable\recovery。
main system
main system是正常运行的Android系统。
通信
Android板子每个时刻只可以处于bootloader、recovery、main system其中的一个模式中,烧写过程中,三个模式之间需要通信,比如:main system通知recovery烧写那个升级包。大致有三种方式可以用来通信:BCB、寄存器和cache分区。
BCB
BCB (bootloader control block)可以用于main system传递数据给bootloader和recovery模式。BCB的内容存在于nand flash的一个独立的分区,可以在nand flash分区表中看到,分区的名称为misc。
通过BCB,main system可以通知bootloader启动到recovery模式下,同时也可以传递命令给recovery,比如烧写哪个文件。
recovery在烧写的过程中,会设置BCB,以确保烧写成功前,一直会开机启动到recovery模式下,这样可以防止烧写过程中断电的情况。
寄存器
main system模式下,运行如下命令会重启,并进入recovery模式:(也可调用android_reboot函数)
reboot recovery
reboot命令实际上是系统调用,最终会调用到内核的kernel_restart函数,该函数最终会设置某个寄存器的位置,然后执行重启操作。
重启后,bootloader会检测到该寄存器的值,并根据其值,启动到recovery模式下。
cache分区
recovery和main system模式下,都会将nand flash的cache分区挂载到cache目录从而实现这两种模式下的通信。比如:main system模式下,下载升级包update.zip,并将其路径设置到文件/cache/recovery/command中,然后重启到recovery模式下,recovery进程会读取到文件/cache/recovery/command中的值,并执行系统升级工作。
升级包
通常升级包的名称为update.zip,它包含了要升级的内容和升级脚本,也就是说,整个升级的过程都由升级包本省控制。
升级脚本解析对应的源码:META-INF\com\google\android\updater-script。可用的命令列表可以参见bootable\recovery\updater\install.c的函数RegisterInstallFunctions()。
解析升级脚本采用语言Edify,源码位置:bootable\recovery\updater和bootable\recovery\edify。
若想自己制作update.zip包,需要使用的一下三个文件:
- out/host/linux-x86/framework/signapk.jar
- build/target/product/security/testkey.pk8
- build/target/product/security/testkey.x509.pem
制作的过程:
- 解压从源码中编译出来的update.zip。
- 修改解压后的文件。
- 重新压成包update.zip
- 使用命令处理update.zip,该命令主要是最zip执行签名操作:java -Xmx1024m -jar signapk.jar -w testkey.x509.pem testkey.pk8 update.zip update_unsigned.zip
- update_unsigned.zip就是最终的升级包。
启动流程
启动流程大致路下:
1.开机后,启动到bootloader下,bootloader会作一些初始化的操作,然后会从三个地方确定后面的动作:
查找SD卡上指定的文件:此种情况,主要用于,通过SD卡,升级系统。只要在SD卡中按照规则放置升级文件和相关的脚本,即可实现系统的升级。
查找按键的状态:此种情况主要用于开机后进入bootloader或者recovery模式,按键也通常是硬件上的几个键按下的状态。
获取BCB的内容:需要根据BCB的内容,来执行具体的操作,通常是进入recovery模式。
若没有发现上述的三种信息,则会按照正常的启动流程,进入main system模式。
2.若需要通过SD卡升级,则会显示升级提示界面,并开始系统升级,完成后,重启进入main system。
3.若需要进入recovery模式,在bootloader模式下,会加载recovery分区到内存,然后进入recovery模式下。
recovery会启动recovery进程,该进程会读取/cache/recovery分区中的内容,决定具体的操作。若没有相关的配置,则进入控制台模式。
4.若需要进入main system模式,则会加载boot分区中的内容,然后进入正常的启动流程。
升级流程
升级的流程大致如下:
1.main system模式下,下载update.zip到/cache目录。
2.设置/cache/recovery/command目录的内容为:--update_package=/cache/update.zip。
3.调用函数android_reboot,并设置进入recovery模式的代码。
4.系统重启,进入recovery模式,并启动recovery进程,该进程会检测/cache/recovery/command的内容,然后升级update.zip。