Android5.0 recovery about update

从Android 5.0开始，即使是update.zip包，也是仿照增量包的方式进行打包了。使用make otapackage得到一个zip文件，查看内容：
boot.img
file_contexts
META-INF
system.new.dat
system.patch.dat
system.transfer.list

显然system.img不再提供，而是提供了三个文件，利用这三个文件的脚本在/META-INF/com/google/android/updater-script文件中：
block_image_update(“/dev/block/platform/msm_sdcc.1/by-name/system”, package_extract_file(“system.transfer.list”), “system.new.dat”, “system.patch.dat”);
而该函数定义在：
bootable/recovery/updater/blockimg.c:BlockImageUpdateFn()中。

代码中有一段注释用于描述transfer list文件的内容，它支持如下命令：
1) 文件的第一行是版本号，当前是1；
2) 文件的第二行是总共需要写入的block数量（后面new命令的range加起来应该等于该值）；
3) erase [rangeset]: 将目标分区的range清除；
4) zero [rangeset]：将目标分区的range使用0填充；
5) new [rangeset]: 将目标分区的range使用new_data文件填充；

比如如下的一个system.transfer.list文件：
1
90270
erase 2,0,262144
new 28,0,32767,32768,32770,32833,32835,33347,65535,65536,65538,98304,98306,98369,98371,98883,124176,131072,131074,163840,163842,163905,163907,196608,196610,229376,229378,229441,229443

第一行1表示该transfer文件的版本为1；
第二行表示new命令总共要写入90270个block；
第三行表示删除的range是从0到262144，2表示range的区间描述数目是2个数值，即0和262144;（此行对应的ioctl操作有可能失败很快返回，反而成功删除时间比较长。）
第四行表示从system.new.dat文件中读取block，然后依次写入如下14个区间：[0, 32767), [32768, 32770) …这个区间的block总数刚好是前面描述的90270个。

这样的做法实际上是一个稀疏数组的区间描述，用以降低update.zip文件的大小和写入的数据量。

更新之后，需要重新启动进系统（block_image_update的第一个参数），否则recovery 等image 可能没有被更新，猜测进入system之后，会有一些更新的动作。