從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之後，會有一些更新的動作。