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数据部分。

转载于:https://www.cnblogs.com/codeking100/p/10339151.html