file_contexts (specified by SELINUX_FC) is needed both when building
and (re)packaging. We used to use the copy in out/ when building, and
looked for the copy in BOOT/RAMDISK/ when packaging from target_files
zip. With system_root_image enabled, the file_contexts needed for
building and packaging might be different from the one on device. So
we explicitly pack the file as META/file_contexts in target_files zip.
Also refactor out the overriding of selinux_fc property into
common.LoadInfoDict().
Change-Id: I94f9ea6671b3792c12c1c21573840743d63da39a
(cherry picked from commit aa7318c384)
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: Id097138bfd065c84eac088b3ad49758010b2927b
(cherry picked from commit 2fd2c9bfd6)
Clockwork builds may rename init.rc to init.core.rc. Change the OTA
script to scan all init.*.rc files to determine the proper location for
install-recovery.sh.
Bug: 22128990
Change-Id: Icad3497d1663e074b938919b40fc239c84fbeb2b
(cherry picked from commit 610754e5ad)
If there is a SELinux context label in the recovery.fstab, we should
honor that when mounting the partition.
Bug: 19764039
Change-Id: Ic80a3377a5a94c9d10dd464eb1257b157a947510
(cherry picked from commit 548eb76c8f)
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: I89ac8fe623b855721b7affd07cf9426a23433ab0
When passing a ZipInfo instance to common.ZipWriteStr(), the
external_attr attribute should not be overwritten unless specified.
We didn't have the issue previously because we were calling
ZipFile.writestr() directly until [1] merged.
[1] commit 2ed665a033.
Bug: http://b/21309935
Change-Id: I374ccd40c174ff9259844f38bdbf187dfe82552d
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: I991169ec307dfb231b2fe8908a0668595ecb2060
In order to work around the zip 2GiB limit, we need to wrap the related
functions in zipfile. Calls to those functions should always be replaced
with calls to the wrappers instead.
Bug: 18015246
Change-Id: Ice494371ca6654e88ded2ae0eb680f51082effcb
It's not necessary to call block_image_verify for the most common
case where we attempt an update for the first time and the target
partition has expected contents. It is sufficient to confirm that
the target partition is intact.
Computing a hash is much faster than simulating the update, which
means this change should make the update speed for v3 much closer
to v2 for the common case. If the update was interrupted, this is
going to make resuming somewhat slower, of course. Hopefully this
should be rather rare.
Bug: 20309033
Change-Id: I04792f3681bf2cd5d9a4e1c41eb883c7f26c6f58
Add vboot properties to the dictionary file, which will be packed into
the target_files zip. Add support in packaging and OTA scripts to
sign the generated bootable images (boot.img and recovery.img) when
vboot is enabled.
Change-Id: I08758ced03d173219415bca762bbdb66c464a9f5
(cherry picked from commit 5d5a3bd9e8d8b14b71d1b2105417a2958d13d3d2)
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
Python 2.7's zipfile implementation wrongly thinks that zip64 is
required for files larger than 2GiB. We can work around this by
adjusting their limit. Note that `zipfile.writestr()` will not work
for strings larger than 2GiB. The Python interpreter sometimes rejects
strings that large (though it isn't clear to me exactly what
circumstances cause this). `zipfile.write()` must be used directly to
work around this.
This mess can be avoided if we port to python3.
The bug (b/19364241) in original commit has been fixed.
Bug: 18015246
Bug: 19364241
Bug: 19839468
(cherry picked from commit cd082d4bfe)
Change-Id: I7b5cc310e0a9ba894533b53cb998afd5ce96d8c6
BlockImageDiff has three versions. Only the incremental OTAs generated
with the latest version (3) can be re-applied to the system that's
already on the target build. Otherwise, operations like move will make
unconditional changes and damage the system. During the verification
phase, abort the OTA update if BlockImageDiff is less than 3 and it
doesn't match the checksum of the source build.
Change-Id: Ic630346eab2a993a84d0aeaacd7167ef62cc24f6
(cherry picked from commit daebaa6ed3)
This will only be used when the block file format is at least
version 3. For V1/V2 (L, L MR1) block versions, fall back to
the old range_sha1 check.
Bug: 19357591
Change-Id: I7cb178b70d48ec3c98cdb88ed1c94cf7797a01d0
(cherry picked from commit cad78c12fb)
Add source and target block hashes as parameters to transfer list
commands that copy or patch data to a partition. This allows the
updater to verify the status of each command in the transfer list
and makes resuming block based OTAs possible. Due to the changes,
update the transfer list version to 3.
Needs matching changes from
I1e752464134aeb2d396946348e6041acabe13942
Bug: 18262110
Change-Id: Ia5c56379f570047f10f0aa7373a1025439495c98
(cherry picked from commit cac671a9d1)
Python 2.7's zipfile implementation wrongly thinks that zip64 is
required for files larger than 2GiB. We can work around this by
adjusting their limit. Note that `zipfile.writestr()` will not work
for strings larger than 2GiB. The Python interpreter sometimes rejects
strings that large (though it isn't clear to me exactly what
circumstances cause this). `zipfile.write()` must be used directly to
work around this.
This mess can be avoided if we port to python3.
Bug: 18015246
Change-Id: I8a476d99c5efdef6ea408373b706e9fbd3a798be
Change boot, recovery, and verity metadata signing keys to use the
same PKCS8 / X.509 PEM format as the other signing keys, and update
build scripts to use correct arguments for the updated signing
tools.
Bug: 15984840
Bug: 18120110
Change-Id: I23ed5a004ecdad6cf7696487935ad5031eb8adf8
(cherry picked from commit 72d90eb189)
Generate version 2 of the block_image_update transfer list format.
This improves patch size by a different strategy for dealing with
out-of-order transfers. If transfer A must be done before transfer B
due to B overwriting A's source but we want to do B before A, we
resolve the conflict by:
- before B is executed, we save ("stash") the overlapping region (ie
the blocks B will overwrite that A wants to read)
- when A is executed, it will read those parts of source data from
the stash rather than from the image.
This reverses the ordering constraint; with these additions now B
*must* go before A. The implementation of the stash is left up to the
code that executes the transfer list to apply the patch; it could hold
stashed data in RAM or on a scratch disk such as /cache, if available.
The code retains the ability to build a version 1 block image patch;
it's needed for processing older target-files.
Change-Id: Ia9aa0bd45d5dc3ef7c5835e483b1b2ead10135fe
When generating incrementals for the system and vendor partitions,
check the first block (which contains the superblock) of the partition
to see if it's what we expect. If this check fails, give an explicit
log message about the partition having been remounted R/W (the most
likely explanation) and the need to flash to get OTAs working again.
Bug: 17393999
Change-Id: Ifd2132b428dbc4907527291712690204a3664ac0
Move BlockDifference into common and make its script generation code
more complete, so that it can be use by releasetools.py to do diffs on
baseband images.
Bug: 16984795
Change-Id: Iba9afc1c7755458ce47468b5170672612b2cb4b3
Replace the xdelta/xz-based block OTA generation with a new system
based on the existing bsdiff/imgdiff tools.
Bug: 16984795
Change-Id: Ia9732516ffdfc12be86260b2cc4b1dd2d210e886
Now that we're building and saving images in the target_files at build
time, we should use those images instead of rebuilding them.
Bug: 17201052
Change-Id: I459e650f66f1e0bdf01ad54df9e34f36bf2ee899
This ensures that when the verity key is rotated to a release key
both the boot and recovery images will be correctly signed. It does
mean that they will both be signed with the same key for now, but
as that doesn't change the threat model separating them is just a
distant nice-to-have.
Bug: 15725238
Change-Id: I5b75e4346fe0655065643ab553431690cc1a8cb0
The AOSP bootimage format allows the use of a second stage image
however the BuildBootableImage function does not allows the "second"
optional argument. This patch adds the support of this argument.
Bug: 17035158
Change-Id: I8ed9d9e56449945c2d42fc908269921c394f68c0
Signed-off-by: Benoit Fradin <benoit.fradin@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Patrick Tjin <pattjin@google.com>
When making bsdiff/imgdiff patches, give up after 5 minutes. (On
certain large files it can take hours to build a patch, if it ever
even completes.)
Change-Id: I123c06f8194f85f6f4e640f7eb31c7746f76ba4d
- Support TARGET_USERIMAGES_USE_F2FS.
- Support BOARD_USERDATAIMAGE_FILE_SYSTEM_TYPE.
- Support "userdata_fs_type" in the prop dict.
- Update build_image to recognize f2fs and call the correct command.
Change-Id: If31cc8bd235f93a4c7814fab36e6e2d13d3037ad
Signed-off-by: JP Abgrall <jpa@google.com>
Make vendor partition a first-class member of the OTA system (for
target_files that contain a VENDOR/ subdirectory).
Build vendor images in a way that is compatible with block-based OTA.
Support updating the vendor partition in both full and incremental,
block and file OTAs. In most cases this is handled by refactoring the
existing code to handle the system partition to handle either, and
then calling it twice.
Currently we don't support incremental OTAs from a target-files
without a VENDOR subdirectory to one with one, or vice versa. To add
or remove a vendor partition a full OTA will need to be done.
Bug: 15544685
Change-Id: I9cb9a1267060bd9683a9bea19b43a26b5a43800d
img_from_target_files.py just skipps the boot.img and recovery.img since
there is no kernel or recovery.fstab for emulator.
Bug: 15383279
Change-Id: I4035193e6ab933194ff1417dfae4eab963fe5301
A separate OEM file must be specified to provide the expected
values for these properties. The list of properties comes from
the "oem_fingerprint_properties" list in misc_info.txt
Bug: b/13367676
Change-Id: I1a3eaf108492132cf6f595a5d1c9f7e0c3cb3142
The system partitions has regions that we shouldn't write and can't
depend on the contents of. Adds a new script to generate a map of
these regions (using the sparse image as input), and include the map
in the package zip so it can be used when writing or patching the
system partition.
Also fixes a bug where the wrong SELinux file contexts are used when
generating incrementals.
Change-Id: Iaca5b967a3b7d1df843c7c21becc19b3f1633dad
The target_files zip should now contain the recovery-from-boot patch
and the script to install it. This means that sign_target_files_apks,
which generates a signed target_files from an unsigned target_files,
now needs to recompute the patch and script (taking into account the
key replacement, property changes, etc., that it does) so its output
contains the correct patch.
Change-Id: I18afd73864ba5c480b7ec11de19d1f5e7763a8c0
Tao Bao