commit | 2903cddb58f6ee99116e0751a2305f75f9a86461 | [log] [tgz] |
---|---|---|
author | Tianjie Xu <xunchang@google.com> | Fri Aug 18 18:15:47 2017 -0700 |
committer | Tianjie Xu <xunchang@google.com> | Tue Sep 05 15:09:58 2017 -0700 |
tree | 22ad221cc46d846313c5ee4e83c36a6494b05beb | |
parent | deb5de0bc144de9f62b0621d8a23db3415e4ac78 [diff] |
Improve imgdiff for large zip files Due to the cache size limit for OTA generation, we used to split large zip files linearly into pieces and do bsdiff on them. As a result, i) we lose the advantage of imgdiff; ii) if there's an accidental order change of some huge files inside the zip, we'll create an insanely large patch. This patch splits the src&tgt more smartly based on the zip entry_name. If the entry_name is empty or no matching source is found for a target chunk, we'll skip adding its source and later do a bsdiff against the whole split source image (this rarely happens in our use cases except for the metadata inside a ziparchive). After the split, the target pieces are continuous and block aligned, while the sources pieces are mutually exclusive. (Some of the source blocks may not be used if there's no matching entry_name in the target.) Then we will generate patches accordingly between each split image pairs. Afterwards, if we apply imgpatch to each pair of split source/target images and add up the patched result, we can get back the original target image. For example: Input: [src_image, tgt_image] Split: [src-0,tgt-0; src-1,tgt-1, src-2,tgt-2] Diff: [ patch-0; patch-1; patch-2] Patch: [(src-0,patch-0)=tgt-0; (src-1,patch-1)=tgt-1; (src-2,patch-2)=tgt-2;] Append: [tgt-0 + tgt-1 + tgt-2 = tgt_image] Peformance: For the small package in b/34220646, we decrease the patch size of chrome.apk dramatically from 30M to 400K due to the order change of two big .so files. On two versions of angler, I also observe decent patch size decrease. For chrome.apk, we reduced the size from 5.9M to 3.2M; and for vevlet.apk from 8.0M to 6.5M. Bug: 34220646 Test: recovery component test && apply imgdiff & imgpatch on two chrome.apk Change-Id: I145d802984fa805efbbac9d01a2e64d82ef9728b
mm -j && m ramdisk-nodeps && m recoveryimage-nodeps # To boot into the new recovery image # without flashing the recovery partition: adb reboot bootloader fastboot boot $ANDROID_PRODUCT_OUT/recovery.img
# After setting up environment and lunch. mmma -j bootable/recovery # Running the tests on device. adb root adb sync data # 32-bit device adb shell /data/nativetest/recovery_unit_test/recovery_unit_test adb shell /data/nativetest/recovery_component_test/recovery_component_test # Or 64-bit device adb shell /data/nativetest64/recovery_unit_test/recovery_unit_test adb shell /data/nativetest64/recovery_component_test/recovery_component_test
recovery-refresh
and recovery-persist
executables exist only on systems without /cache partition. And we need to follow special steps to run tests for them.
Execute the test on an A/B device first. The test should fail but it will log some contents to pmsg.
Reboot the device immediately and run the test again. The test should save the contents of pmsg buffer into /data/misc/recovery/inject.txt. Test will pass if this file has expected contents.
ResourceTest
validates whether the png files are qualified as background text image under recovery.
1. `adb sync data` to make sure the test-dir has the images to test. 2. The test will automatically pickup and verify all `_text.png` files in the test dir.