recovery的一些开发点滴
Android的recovery是我在公司做的最多的，应该也是我在Android中了解的较为深入的一个部分。recovery这部分其实Android本身都已经提供了很完善的一套机制，但是因为公司是做机顶盒的，所以在因为平台订制的关系，recovery这部分还是做了很多修改的。首先，修改的比较少的是OTT这种盒子，本次也主要讲这种，其实这种和手机区别不大。而类似将DVB 中的loader和Android的recovery整合到一起这种，确实比较不一样。例如在我们公司，整个升级的签名校验订制以及升级所用到的update.zip包中的烧录进程就都是自己一套的。但是万变不离其中，其实了解了就发现其实也都是那样。 所以简单讲下recovery的相关知识： 如何进入recovery 标准Android的recovery进入方式一般是这几种”在设置中点击恢复出厂设置“”开机按组合件进入recovery“，例如 home + power（这种是手机的）”系统检测到固件更新，下载后要求你重启，这时重启会先进入recovery“其实这几种在实现上是差不多：1、首先，我们要明白，在Android中，其实是由两个系统存在的，recovery，其实就是一个小系统，专门用来刷机的。2、具体是要进入哪个系统，这个是又fastboot来决定的（因为你基本可以认为他就是开机的第一个程序），他决定进那个就哪个。当然，这个也是由我们来告诉fastboot的。3、怎么告诉呢？有两种方式。第一种，就是按组合键，（就相当于，我们告诉fastboot，开机检测到有人按了这个组合件就是进recovery，别进安卓。这个当然就可以定制了，例如在机顶盒，我们通常是改成按遥控器，如”连续按上中下键“）。第二种，就是Android告诉fastboot下次启动进recovery，然后Android自己再重启。这个就关系到了另一个分区，叫MISC（你基本可以认为他就是存储recovery命令的）。因为fastboot启动会去读这个MISC分区中的内容，来决定自己进哪个系统。系统固件升级和恢复出厂都属于这种，就是recovery命令有点不一样。 recovery流程 首先要知道一点，recovery系统是一个类似Linux的变种，使用了Android init的那一套，但是不会进去虚拟机。所以init.rc和property那些Android的东西对于recovery还是一样的。 流程如下：1、一般来说，在init.reovery.rc中，就可以看到启动了/sbin/recovery，这就启动了recovery来作为一个service2、recovery进程简介： 1. load_volume_table();这个函数从”/etc/recovery.fstab”读取分区信息2. get_arg()：主要就是获取recovery的命令、参数等等，这样recovery进程才知道自己要做什么，升级包在哪，这些都以一定的结构体保存在MISC分区中，我们成为bootloader_message，也就是下面会说的BCB。 ①get_bootloader_message()：主要工作是根据分区的文件格式类型（mtd或emmc）从MISC分区中读取BCB数据块到一个临时的变量中。（get和set bootloader_message：1、/从”/misc”读取分区设置/2、/mtd类型只读取或者修改MISC_COMMAND_PAGE一页/3、/emmc类型直接对一个device进行读写操作/） ②然后开始判断Recovery服务是否有带命令行的参数（/sbin/recovery，根据现有的逻辑是没有的），若没有就从BCB中读取 recovery域。如果读取失败则从/cache/recovery/command中读取然后写入BCB临时变量。这样这个BCB的临时变量中的recovery域就被更新了。在将这个BCB的临时变量写回真实的BCB之前，又更新的这个BCB临时变量的command域为“boot-recovery”。这样做的目的是如果在升级失败（比如升级还未结束就断电了）时，系统在重启之后还会进入Recovery模式，直到升级完成。 ③在这个BCB临时变量的各个域都更新完成后使用set_bootloader_message()写回到真正的BCB块中。这个过程可以用一个简单的图来概括，这样更清晰：（get_arg()这个函数中，主要是获取参数，重写recovery命令到BCB。但是，有时从command_file，有时从BCB读取。看如何从上层进入recovery，从上层重启进入recovery的话，会将recovery命令写入到BCB，将升级包目录写进command_file。也就是说，command_file是不会有recovery标识的。） // --> write the arguments we have back into the bootloader control block // always boot into recovery after this (until finish_recovery() is called) strlcpy(boot.command, "boot-recovery", sizeof(boot.command)); strlcpy(boot.recovery, "recovery\n", sizeof(boot.recovery)); 1 2 3 4 1 2 3 4 （所以说，从BCB读出，在写回，主要就是修改这两句话。这样子，就能保证进入升级。要注意的是，进入升级模式，是在fastboot的过程选择的，而这里是为了保证升级过程中若中断了，下次还是进recovery。第二种是如果BCB读取失败 还可以从command file中去读取。） 接下来就是判断从上面流程获取的recovery命令及参数了3. if(update_package)：判断update_package是否有值，若有就表示需要升级更新包，此时就会调用 install_package()。在这一步中将要完成安装实际的升级包。这是最为复杂，也是升级update.zip包最为核心的部分。（这种就是所谓的固件升级）4. if(wipe_data/wipe_cache)：这一步判断实际是两步，在源码中是先判断是否擦除data分区（用户数据部分）的，然后再判断是否擦除cache分区。值得注意的是在擦除data分区的时候必须连带擦除cache分区。在只擦除cache分区的情形下可以不擦除data分区。（这种就所谓的恢复出厂设置） finish_recovery()：这是Recovery关闭并进入Main System的必经之路。其大体流程如下：① 将intent（字符串）的内容作为参数传进finish_recovery中。如果有intent需要告知Main System，则将其写入/cache/recovery/intent中。这个intent的作用尚不知有何用。② 将内存文件系统中的Recovery服务的日志（/tmp/recovery.log）拷贝到cache（/cache/recovery/log）分区中，以便告知重启后的Main System发生过什么。③ 擦除MISC分区中的BCB数据块的内容，以便系统重启后不在进入Recovery模式而是进入更新后的主系统。④ 删除/cache/recovery/command文件。这一步也是很重要的，因为重启后Bootloader会自动检索这个文件，如果未删除的话又会进入Recovery模式。原理在上面已经讲的很清楚了。 install_package() 上面已经说过，这个基本是整个recovery最复杂的也是最核心的部分，就是他完成刷机（固件升级）。详细说下： ①ensure_path_mount()：先判断所传的update.zip包路径所在的分区是否已经挂载。如果没有则先挂载。②load_keys()：加载公钥源文件，路径位于/res/keys。（下面讲）③verify_file()：对升级包update.zip包进行签名验证。（下面讲）④mzOpenZipArchive()：打开升级包，并将相关的信息拷贝到一个临时的ZipArchinve变量中。这一步并未对我们的update.zip包解压。⑤try_update_binary()：在这个函数中才是对我们的update.zip升级的地方。这个函数一开始先根据我们上一步获得的zip包信息，以及升级包的绝对路径将 update_binary文件拷贝到内存文件系统的/tmp/update_binary中。以便后面使用。⑥pipe()：创建管道，用于下面的子进程和父进程之间的通信。父进子出。⑦fork()：创建子进程。其中的子进程主要负责执行binary（execv(binary,args)，即执行我们的安装命令脚本），父进程负责接受子进程发送的命令去更新ui显示（显示当前的进度）。子父进程间通信依靠管道。⑧其中，在创建子进程后，父进程有两个作用。一是通过管道接受子进程发送的命令来更新UI显示。二是等待子进程退出并返回INSTALL SUCCESS。其中子进程在解析执行安装脚本execv(binary,args)的作用就是去执行binary程序，这个程序的实质就是去解析update.zip包中的 updater-script脚本中的命令并执行。由此，Recovery服务就进入了实际安装update.zip包的过程。 实际上，上面已经说完了主要流程，其实也比较简单，所以接下来做一点细节的补充： 细节补充 Install_package()中load_keys和verify_file/返回key和key的个数，key的位置在 “/res/keys”/1.RSAPublicKey* loadedKeys = load_keys(PUBLIC_KEYS_FILE, &numKeys);key的结构如下：*{key->len,key->n0inv,{key->n[i]},{key->rr[i]}}*或者v2 {key->len,key->n0inv,{key->n[i]},{key->rr[i]}}*example”{64,0xc926ad21,{1795090719,…,-695002876},{-857949815,…,1175080310}}”“v2 {64,0xc926ad21,{1795090719,…,-695002876},{-857949815,…,1175080310}}”/Key的版本不同的话，幂分别是3和65537 /*对zip包数据进行校验。对zip包的签名部分进行摘要计算(sha)，再利用key对摘要2.err = verify_file(path, loadedKeys, numKeys); Zip包结构1：主要数据，已经经过签名2：end-of-central-directory 包括comment_size + EOCD_HEADER_SIZE其中(eocd[0] = 0x50 eocd[1] = 0x4b eocd[2] = 0x05 eocd[3] = 0x06)（用于指纹校验）RSA块：经秘钥加密，可用于签名校验。3：footer：(2-byte signature start)ffff (2-byte comment size)其中comment_size = footer[4] + (footer[5] << 8);eocd_size = comment_size + EOCD_HEADER_SIZE;signature_start = footer[0] + (footer[1] << 8);signature_start - FOOTER_SIZE这个大小用来存放RSA block.（这算一步小校验）signed_len：except for the comment length field (2 bytes) and the comment data. 利用上面几个固定的字节对应的固定的值，可以进行指纹校验，这是第一步和第二步的校验第三步校验504b0506 若出现在正确的位置后面的话，则”EOCD marker occurs after start of EOCD第四步校验就是对/zip包的前部分，SHA_update(&ctx, buffer, size);摘要计算/过程SHA_init(&ctx);SHA_update(&ctx, buffer, size);//一次会处理4096字节const uint8_t* sha1 = SHA_final(&ctx);得到摘要结果/利用公钥 对摘要进行校验，上一步得到的/RSA_verify() Zip包的后面是RSA区和6个字节的脚信息，RSA区是明文用私钥加密后的数据，机顶盒中会有一个公钥。先对前面的升级数据进行SHA1，然后用公钥对RSA区数据进行解密。解密后的数据的前半部进行 pkcs1.5 padding bytes.校验。解密后的数据的后半部和SHA1后的数据进行比较，完成校验。（20个字节） updater-script脚本部分函数说明升级脚本文件updater-script的内容可根据自己需要进行修改。对脚本中的部分函数进行简要说明： z ui_print(char *str)功能：打印信息。参数：str指针指向要打印的信息地址。 z show_progress (char *sec，char *total)功能：显示进度条。参数：− sec：多少秒更新一次进度条，一般为1。− total：升级所耗时间（根据升级包大小来确定）。 z format(charfs_type, char *partition_type,char *location,charfs_size, char *mount_point)功能：格式化分区。参数：− fs_type：文件系统类型（“ubifs”or“ext4”，“raw”）。¾ NAND Flash器件：裸分区：raw；文件系统分区：ubifs。¾ eMMC器件：裸分区：不支持；文件系统分区：ext4。− partition_type：器件类型（“MTD”or“EMMC”）。− location：分区名或者分区对应的设备节点。¾ NAND Flash器件，分区名：system。¾ eMMC器件分区，对应的设备节点： /dev/block/platform/hi_mci.1/byname/syste。− fs_size：0表示擦除整个分区。− mount_point：分区挂载点。 z package_extract_file(char *package_path, char *destination_path)功能：从zip包中提取单个文件。参数：− package_path：解压的文件。− destination_path：解压到的目标路径。 z write_raw_image (char *file, char *partition)功能：将单个文件写入分区。参数：− file：欲写入的文件。− partition：欲写入的分区。 z mount(char *fs_type, char *partition_type, char *location, char *mount_point)功能：挂载特定分区到某目录下参数：− fs_type：文件系统类型（“ubifs”or “ext4”）。− partition_type：器件类型（“MTD”or “EMMC”）。− location：分区名字或者分区对应的设备节点。¾ NAND Flash器件，分区名：system¾ eMMC器件分区，对应的设备节点：/dev/block/platform/hi_mci.1/by-name/system− mount_point：挂载点。 z unmount(char *mount_point)功能：卸载分区。参数：− mount_point：分区挂载点。 z package_extract_dir(char *package_path, char *destination_path)功能：直接提取一文件夹并直接解压到相应目录。参数：− package_path：zip压缩包里面要提取的文件夹名。− destination_path：解压到的目录。 z symlink(char *name, char *argv[])功能：将argv* 指向的内容全部链接到name文件。参数：− name：想要链接到的文件名。− argv：想要链接的文件。 z set_perm_recursive (int uid, int gid, int dir_mode, int file_mode,char *path)功能：修改目录权限及目录内文件的权限。参数：− uid：用户id。− gid：组 id。− dir_mode：目录权限。− file_mode：目录内文件权限。− path：目录路径。 z partchange(char *partition_type, char *new_partition)功能：依据传入的分区信息，在内核中建立新的分区参数：− partition_type：器件类型（“MTD”or “EMMC”）− new_partiton：分区信息− EMMC器件：关键字是：dev/block/mmcblk0− MTD器件：关键字是：hinandpartchange函数不支持spi器件,支持Nand Flash,eMMC器件 z setmisc(char *partition_type, char *location)功能：写misc标记位− partition_type：器件类型（“MTD”or“EMMC”）− location：分区名字或者分区对应的设备节点。¾ NAND Flash器件，分区名：misc¾ eMMC器件分区，对应的设备节点：/dev/block/platform/hi_mci.1/by-name/misc 增量升级及升级包的制作 很多时候，我们要升级的固件和上一个版本差的只是一两个APK或者是多了一些库文件，这个时候，如果我们再升级这个system分区，即升级整个system.img就做了很多务必要的工作，而且耗费的流量太大。从上面的升级脚本看到，其实完全是可以将某个文件\目录按照指定的属性添加到指定的目录下的，同时也可以删除掉某个指定的文件\目录。这个就是增量升级。本来，在Android源码中./build/tools/releasetools/ota_from_target_files -n -i <旧包> <新包> <差分包名> 是可以制作OTA增量升级包的，但是一般，不会这么干，因为这种做法太蠢了。那怎么做呢，从上面的一大堆话中，其实可以知道升级就是按照按照升级脚本来的。所以，升级包（rom包）制作方式：1、改一个自己需要的升级脚本，可以试增量升级，也可以是整个镜像升级。（当然脚本还是放在哪个目录下，然后update-binary也得支持这些脚本命令才行）2、然后把要的东西（APK,库,镜像）和升级脚本打包成一个update.zip，在用源码中的key给这个升级包进行签名，然后就做成一个可以用的升级包了。（当然了，手机刷机常用的rom包，其实也是一样的，不过这个时候就是升级整个system.img，或者根据需要再升级某些指定的分区。）怎么签名：Java-jar out/host/linux-x86/framework/signapk.jar -w build/target/product/security/testkey.x509.pem build/target/product/security/testkey.pk8 ~/export/update_signed.zip ~/export/updatesigned.zip 之前讲过Android中recovery的基本知识。在工作中，需要做的经常是对标准recovery做一些定制化，所以这篇文章，记录下这段时间的一些心得： 1、增量升级: 在源码根目录下自行make otapackage 会生成升级包，两次编译后包用下面工具：./build/tools/releasetools/ota_from_target_files -n -i <旧包> <新包> <差分包名> ，可以制作增量升级包。这里必须用中间生成的包才行。改进方法：前面说的可以自己写一个简单的Linux脚本，把修改后的升级脚本和文件进行打包签名，这样可以比源码中直接make otapackage效率要高一些，同时也更灵活。有时你这个版本只是多了一两个APK，就可以在脚本用mount挂在system分区->package_extract_file直接将APK解压到制定的目录。 2、添加一些脚本命令： 例如，现在这个版本是想要减掉上一个版本的一个system/app/下的一个APK，如果我们可以自己给脚本解析器增加一个delete的命令。例如，增加设置命令的接口来给fastboot发送命令，让recovery系统去告诉fastboot去完成一些只能在fastboot中完成的工作。遇到两次需要这样做：（1）当时，有一个工作是要求在recovery中增加重新划分分区的功能，因为这个工作只能在fastboot中完成，所以我就是这样做的。（2）还有一次是恢复出厂设置后，有些fastboot中的env需要重新设置，才能算是真正的恢复出厂，就也是让recovery去告诉fastboot重新设置下env。 3、修改升级时的画面： 这个基本每次都要做的，如果只是使用安卓原本的recovery来做的话，就只要去源码下bootable/recovery/res/images把图片换换，然后修改下位置和一些简单的细节就可以了。不过了解下它的实现也好： Recovery UI 在recovery源代码recovery.cpp中main有 Device* device = make_device(); ui = device->GetUI(); gCurrentUI = ui; ui->Init(); ui->SetLocale(locale); ui->SetBackground(RecoveryUI::NONE); if(show_text) ui->ShowText(true); 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 （1）首先新建了一个Device类的对象， Device类封装了一些操作，包括UI的操作（2）调用Device类的GetUI()返回一个DefaultUI对象，recovery中涉及到三个UI类，三个类之间为继承关系，分别为DefaultUI、 ScreenRecoveryUI、RecoveryUI（3）调用DefaultUI类的Init(), DefaultUI类没有Init()方法，因此将调用它的父类ScreenRecoveryUI的Init()（4）同理，调用ScreenRecoveryUI类的SetLocale()来标识几个比较特别的区域（5）同理，调用ScreenRecoveryUI类的SetBackground()设置初始状态的背景图（6）显示recovery的主界面，即一个选择菜单graphics.c给出一些接口，这些接口会调用Pixelflinger的源代码给出的接口，以下是部分接口。Pixelflinger库来进行渲染。 附上minui部分接口的说明，供参考 int gr_init(void); /* 初始化图形显示,主要是打开设备、分配内存、初始化一些参数 */ void gr_exit(void); /* 注销图形显示,关闭设备并释放内存 */ int gr_fb_width(void); /* 获取屏幕的宽度 */ int gr_fb_height(void); /* 获取屏幕的高度 */ gr_pixel *gr_fb_data(void); /* 获取显示数据缓存的地址 */ void gr_flip(void); /* 刷新显示内容 */ void gr_fb_blank(bool blank); /* 清屏 */ void gr_color(unsignedcharr, unsignedcharg, unsignedcharb, unsignedchara); /* 设置颜色 */ void gr_fill(intx,inty,intw,inth); /* 填充矩形区域,参数分别代表起始坐标、矩形区域大小 */ int gr_text(intx,inty,constchar*s); /* 显示字符串 */ int gr_measure(constchar*s); /* 获取字符串在默认字库中占用的像素长度 */ void gr_font_size(int*x,int*y); /* 获取当前字库一个字符所占的长宽 */ void gr_blit(gr_surface source,intsx,intsy,intw,inth,intdx,intdy); /* 填充由source指定的图片 */ unsigned int gr_get_width(gr_surface surface); /* 获取图片宽度 */ Unsigned int gr_get_height(gr_surface surface); /* 获取图片高度 */ /* 根据图片创建显示资源数据,name为图片在mk文件指定的相对路径 */ int res_create_surface(constchar* name, gr_surface* pSurface); void res_free_surface(gr_surface surface); /* 释放资源数据 */ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 screen_ui.cpp给出了设置的流程，跟踪这个代码可以知道显示的方法，要注意的是，显示文字的界面必须在showtext为TRUE的时候才会显示，所以用此方法来实现进程界面和选择界面的变换。 4、字体修改 字体比较麻烦吧，我记得我修改字体的时候，觉得很麻烦，不清楚有没有比较好的方法。我的方法：先在graphics.c文件中修改字体头文件。然后：（1）在recovery/miniui中有制作头文件的源码mkfont.c，在/recovery/font中有字体图片，需用gimp工具得到mkfont.c编译所要的结构体。注意gimp输出.c文件时，全部选项都不要选。（2）制作的字体文件.h存在的不足是底色和字体色的问题。修改mkfont.c文件让其相反输出即可。（3）在graphics.c文件中的static void gr_init_font(void)//字体函数是对字体的初始化，在这里是判断字体头文件中的字体，根据阈值0x80来选择透明度，源码默认是255，所以无论怎么调色，最后都是黑色（4）对颜色的修改就要先修改第3点所述部分，再在int gr_text(int x, int y, const char *s)增加想要的字体颜色即可，如：gr_color(255,255,255,252); 5、语言 有时，机器给不同国家，recovery也就要求显示不同语言，那就用这个函数：SetLocale， 该函数根据locale判断所用的字体是否属于阿拉伯语系，阿拉伯语的书写习惯是从右到左，如果是阿拉伯语系的话，就设置一个标志，后面根据这个标志决定从右到左显示文字或进度条。 SetLocale的参数locale赋值逻辑是这样的，先从command文件中读取, command文件中设置locale的命令如”–locale=zh_CN“，如果没有传入locale,初始化过程中会尝试从/cache/recovery/last_locale中读取locale, 如果该文件也没有，则locale不会被赋值，就默认用English.这个其实也是在setting中设置的，会设置为env保持在fastboot中。（我用的方案是这样，不清楚是不是安卓原本的） 6、recovery备份分区 7、增加备份与备份恢复 8、恢复最初升级包的两种方案 9、硬件信息与软件信息
