system.transfer.list深度解析
system.transfer.list system.new.dat
很明显，通过名字我们就知道这两个文件的作用，system.new.dat为数据部分，system.transfer.list为转换的描述列表，我们可以通过这两个文件完成升级。
我们打开一个升级包的升级脚本META-INF\com\google\android\updater-script
block_image_update("/dev/block/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");
调用的是block_image_updater接口，传入system.transfer.list及system.new.dat文件来实现升级。
block_image_updater的代码实现在
bootable/recovery/updater/blockimg.cpp中：
void RegisterBlockImageFunctions() {
RegisterFunction("block_image_verify", BlockImageVerifyFn);
RegisterFunction("block_image_update", BlockImageUpdateFn);
RegisterFunction("block_image_recover", BlockImageRecoverFn);
RegisterFunction("check_first_block", CheckFirstBlockFn);
RegisterFunction("range_sha1", RangeSha1Fn);
}
想了解具体实现的过程，可以另行深入研究，本文不再探讨。
我们来看看system.transfer.list：
3
133943
0
0
new 48,0,32770,32897,32899,33411,65535,65536,65538,98304,98306,98433,98435,98947,131071,131072,131074,163840,163842,163969,163971,164483,195737,196608,196610,229376,229378,229505,229507,230019,235652,262144,262146,294912,294914,295041,295043,327680,327682,360448,360450,393216,393218,425984,425986,458752,458754,491520,491522
zero 70,32770,32897,32899,33411,65535,65536,65538,66050,97792,98304,98306,98433,98435,98947,131071,131072,131074,131586,163328,163840,163842,163969,163971,164483,195737,196608,196610,197122,228864,229376,229378,229505,229507,230019,235652,236164,261632,262144,262146,262658,294400,294912,294914,295041,295043,295555,327168,327680,327682,328194,359936,360448,360450,360962,392704,393216,393218,393730,425472,425984,425986,426498,458240,458752,458754,459266,491008,491520,491522,492034
erase 24,66050,97792,131586,163328,197122,228864,236164,261632,262658,294400,295555,327168,328194,359936,360962,392704,393730,425472,426498,458240,459266,491008,492034,524288
其中：
3 ： 为transfer的版本，目前已经支持从1-4版本
133943：为总共new的block数量。
0： stash slots没有使用，所以这里两个都是0
0：
new：需要写入的block块范围总数：总共48个范围，【0-32770】 【32897-32899】【33411-65535】......
zero：需要填充0的block块范围总数：总共70个范围，【32770-32897】 【32899-33411】.......
erase：需要擦除的block块范围总数：总共24个范围，【66050-97792】 【131586-163328】.......
system.transfer.list是由build/tools/releasetools/blockimgdiff.py生成的，我们来验证下前面几个参数：
out.insert(0, "%d\n" % (self.version,)) # format version number
out.insert(1, "%d\n" % (total,))
# v3+: the number of stash slots is unused.
out.insert(2, "0\n")
out.insert(3, str(max_stashed_blocks) + "\n")
with open(prefix + ".transfer.list", "wb") as f:
for i in out:
f.write(i)
第一行是版本，第二行是total的block数量，由于没有使用stash，第三行四行为0。
我们再次验证下总共写入的total是否正确。
1.我们先确认block的大小，blockimg.cpp中定义为4K
static constexpr size_t BLOCKSIZE = 4096;
2.确认升级包中system.new.dat的大小，其值为548630528
$ ls -l system.new.dat
-rwxr--r-- 1 xxxxxx.xx szsoftware 548630528 Mar 19 16:37 system.new.dat
3.我们再来计算下总共需要写入的total
total=system.new.dat/block=548630528/4096=133943，刚好即为写入的总的total。
我们再来看看这些所有的new zero erase的描述区间 【0-32770】【32770-32897】【32897-32899】...【66050-97792】...【492034-524288】 new zero new erase erase
总共524288个block需要处理 524288*4096=2147483648byte=2048Mb=2G 正好为我们ext4 system 分区的大小，也就是我们把整个2G的system分区按照4096的大小分割，然后给每个block赋予了new/zero/erase的属性，然后保存到transfer.list文件，把所有需要new的数据，生成了new.dat文件。
在最新的version=4的版本中，我们发现system.new.dat文件不见了，增加了vendor.new.dat.br文件，并且计算的时候，发现了vendor.new.dat.br文件打大小变小了，原来是最新的版本，加入了压缩功能，vendor.new.dat.br为采用压缩后的block数据部分。
