partition has unexpected contents概率性问题处理

partition has unexpected contents问题，这类我们一般按刷机流程或者编译流程不对进行处理，不过也有概率性出现不匹配的情况，大概接触了几次，找到了大概的解决方案

1、先看last_log
partition has unexpected contents

[  159.613007] failed to read blocks for diff

[  159.613190] failed to execute command [bsdiff 32488110 27943 8f2f3c9c7b1c2d300acba5a4cb615040db6a0ceb c79b8b53d58a8c343a92623f047865e796b4f53d 424,1,144,145,297,32673,32674,32675,32676,32677,32678,32679,32680 ......

 

transfer.list 中执行bsdiff的时候出错了，能查出来这个报错是那个文件是最关键的，顺藤摸瓜

 

首先要理解这一行的意思是什么，之前的文档中提到过

bsdiff 0 3169086 ffc645d03fa4f56e72fefa872b792a76c26f9bb44bc0c9ddf123d54a04c800824c0951873e195ef1 2,295583,311859 16290 2,295583,311873

 

格式："cmdname" +"patch offset" + "patch length" + "source hash" +"target hash" + "tg block pos" + "sourceblocknum" + "source block pos"

 

解析：读取源block区间数据（block 295583至block 311873,hash值为 ffc645d03fa4f56e72fefa872b792a76c26f9bb4），与system.patch.dat文件里偏移量为0，长度为3169086的数据进行bsdiff差分算法运算，生成的新数据存储至目标块区间blokc 295583至block 311859(hash值为4bc0c9ddf123d54a04c800824c0951873e195ef1）。

 

2、查询具体报错文件

 

起初我是想通过8f2f3c9c7b1c2d300acba5a4cb615040db6a0ceb hash值去查询，但是transfer.list中的这个hash其实是block区间，所以其实查不出什么信息

 

查看了做包的log发现，其实log输出中会有每个文件的bisdiff区间

       306   17137664 (  0.00%)  bsdiff /system/lib/libstagefright_foundation.so 373440-373473 406117-406150

    20851   17137664 (  0.12%)  bsdiff /system/lib/libstagefright_soft_hevcdec.so 374049-374168 406725-406844

     4719   17137664 (  0.03%)  bsdiff /system/lib/libstagefright_soft_mpeg4enc.so 374272-374312 406948-406988

 

输出打印的代码如下：

        print("%10d %10d (%6.2f%%) %7s %s %s %s" % (

             xf.patch_len, tgt_size, xf.patch_len * 100.0 / tgt_size,

             xf.style,

             xf.tgt_name if xf.tgt_name == xf.src_name else (

                 xf.tgt_name + " (from " + xf.src_name + ")"),

             xf.tgt_ranges, xf.src_ranges))

所以我们可以根据打印出错的区间去做包log里面搜索下，就可以查询出具体报错的文件，那么接下来的处理就比较简单，

 

3、整包升级该文件

将APK整个升级，不做差分处理，就可以解决这个问题，

    if "__NONZERO" in tgt_name:

      self.style = "new"

 

其实这种方法不是很严谨，也不是很准确，不过目前遇到两次类似的，都得到了解决