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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值