The major issue with the existing implementation is unnecessarily
holding too much data in memory, such as HashBlocks() which first reads
in *all* the data to a list before hashing. We can leverage generator
functions to stream such operations.
This CL makes the following changes to reduce the peak memory use.
- Adding RangeSha1() and WriteRangeDataToFd() to Image classes. These
functions perform the operations on-the-fly.
- Caching the computed SHA-1 values for a Transfer instance.
As a result, this CL reduces the peak memory use by ~80% (e.g. reducing
from 5.85GB to 1.16GB for the same incremental, as shown by "Maximum
resident set size" from `/usr/bin/time -v`). It also effectively
improves the (package generation) performance by ~30%.
Bug: 35768998
Bug: 32312123
Test: Generating the same incremental w/ and w/o the CL give identical
output packages.
Change-Id: Ia5c6314b41da73dd6fe1dbe2ca81bbd89b517cec
Pad the sparse image with a zero fill chunk to correctly position
verity and FEC metadata at the end of the partition.
Bug: 27073791
Change-Id: I9f70d579a42e5007d50e9c02a98a608d2815f0ed
(cherry picked from commit 6a8781a251)
For squashfs, we currently don't have a system.map. So the whole system
image will be treated as a single file. But for some unknown bug, the
updater will be killed due to OOM when writing back the patched image to
flash (observed on lenok-userdebug MEA49). Prior to getting a real fix,
we evenly divide the non-zero blocks into smaller groups (currently 1024
blocks or 4MB per group).
Bug: 23227672
Change-Id: Ifeddd8d802f01f8cd2a743a1d1217a284fb6e182
dm-verity may touch some blocks that are not in the care_map due to
block device read-ahead. It will fail if such blocks contain
non-zeroes. As a workaround, we mark them as extended blocks and
zero out explicitly to avoid dm-verity failures.
Bug: 20881595
Change-Id: I54e24e70ad822c0d6d7af43301f74d24505f4461
In certain cases, we may have no mapping of ZERO or NONZERO blocks in
the image (such as squashfs at the moment). Don't write those groups if
they are empty.
Change-Id: I82aa05fbbd79130b08868585edd5298e531c4f5a
Similar to the assertations in file-based OTA, we perform verification
for block-based OTAs (BBOTAs) after updating a partition, for both of
the incremental and full OTAs. It increases the update time (~20s on
Nexus 6), but will capture unnoticed errors right away.
Bug: 21500869
Change-Id: I0f8b27734caaa0f41f9c1b904d55af2112784a68
(cherry picked from commit 68658c0f4f)
In ext4 filesystems, some blocks might be changed even being mounted
R/O, such as the superblock (block 0). We need to exclude such blocks
from integrity verification. Plus such blocks should always be
written to the target by copying instead of patching.
Bug: http://b/20939131
Change-Id: I657025b7b1ad50d4365e7b18dc39308facfe864e
(cherry picked from commit ff7778166b)
This caught a few bugs/syntax errors (a few character classes were not
escaped properly in regex patterns, some indentation was illegal,
etc).
Change-Id: I50637607524e68c4fb9cad7167f58a46b8d26b2c
Replace the xdelta/xz-based block OTA generation with a new system
based on the existing bsdiff/imgdiff tools.
Bug: 16984795
Change-Id: Ia9732516ffdfc12be86260b2cc4b1dd2d210e886
