common.AVB_VBMETA_PARTITIONS was recently added (commit
08c190fc89) for the same purpose.
Test: TreeHugger
Change-Id: I65572d54c22a753fdef80677377fcc9b684ee16f
merge_target_files.py step.
Bug: 134681035
Test: Built a merged build and ensured that the new timestamp was
visible in the log.
Change-Id: Ia6bbda48c7f57afdb6482253eaf0b3b0ea067468
Also fixes small nit from previous change to write_sorted_data().
Bug: 132788610
Test: python -m unittest test_merge_target_files
Test: Creating and booting a merged build.
Change-Id: I3dc43a4fe55b86b436dec08feb5d70096d38de36
When using Verified Boot 2.0, releasetools specifies a salt value based
on build fingerprint, so that to give idempotent images.
However, the change that removed static `ro.build.fingerprint` [1] broke
the behavior, as common.LoadInfoDict still relies on fingerprints.
Without a fixed salt, the first call to make_recovery_patch.py and the
second one (which writes IMAGES/{boot,recovery}.img) will see different
images, which leads to install-recovery.sh failure.
Note that currently there's a dependency that requires getting bootable
images through two separate calls. make_recovery_patch.py has to happen
first to get (placeholder) files in the system image. We then generate
canned fs_config files, and finally use add_img_to_target_files.py to
write the images.
This CL adds a quick workaround to force rebuilding the
recovery-from-boot patch while calling add_img_to_target_files.py.
[1] https://android-review.googlesource.com/c/platform/build/+/892933
Bug: 134123803
Bug: 134525174
Test: TreeHugger
Test: Build a non-A/B target that uses AVB. Run validate_target_files.py
on the generated target_files.zip.
Change-Id: I5859e30be63bfd54398cf41fd2d907f15285f560
Chained vbmeta partitions (vbmeta_system, vbmeta_vendor) were added to
support dynamic partitions. validate_target_files.py misses the logic in
handling such partitions.
Bug: 132882632
Test: Run validate_target_files.py on a target_files.zip that uses
chained vbmeta_system partition.
Change-Id: Id06c575d13d5e9cc1b621f485ceb75d3e354c39f
Merged-In: Id06c575d13d5e9cc1b621f485ceb75d3e354c39f
(cherry picked from commit 814b14b3f7)
This is to prevent a user from accidentally including files from the
wrong build. For example, adding any SYSTEM/ line to other_item_list
while keeping SYSTEM/* in system_item_list would cause the other build
to introduce an extra or changed file in the system image.
Bug: 132730710
Test: python -m unittest test_merge_target_files
Change-Id: Ic1178cdc9b991114f293ff3f2b4e6054e06647c6
If the device has neither an OEM nor a vendor partiton,
$PRIVATE_PARTITION_LIST will be empty, causing the fsconfig tool to fail
because the "--all-partitions" argument will be empty.
Quote the comma-substituted "$(PRIVATE_PARTITION_LIST)" - which may be
empty - to appease argparse, which will then populate "_all_partitions"
with an empty "str" object.
Checking _all_partitions against None is superfluous since either
argparse will catch the empty argument and fail early, or the argument
will be a string, in which case it will not be None.
Signed-off-by: Felix <google@ix5.org>
Change-Id: I236e30445b303b4945467b5dc4387d54b5d984f9
This enables mixed builds to use the file_contexts.bin from the system
build when regenerating images that come from system target files, and
similarly for file_contexts.bin from the other build when regenerating
images from other target files.
In monolithic (non-mixed) builds all image-specific selinux_fc props
point to the same file_contexts.
Bug: 132108151
Test: Built and booted mixed build devices.
Change-Id: Id51ed6d96ea6337879f1ab21d47c93c67bc25312
In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink:
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Test: make dist with an odm.img, checks $OUT/odm/etc/build.prop is loaded
Change-Id: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
Merged-In: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
(cherry picked from commit 6c62884000)
Bug: 131437873
Test: Built system-only and vendor builds for merge. Compared
resulting apkcertx and apexkeys text files to that of a monolithic
build,
Test: Created colliding entries in both apexkeys and apkcerts text
files and ensure the script exited with an appropriate error message.
Test: Created unit tests to cover both non-colliding and colliding
entries
Change-Id: I6e42ce682ffa9059344e8cd63ba3a720c1f93452
This CL moves SignApex() from sign_target_files_apks into apex_utils,
and adds sign_apex that allows signing a standalone APEX file directly.
Test: Run the following command and check the output file.
$ build/make/tools/releasetools/sign_apex.py \
-v \
--container_key \
build/make/target/product/security/testkey.x509.pem \
--payload_key external/avb/test/data/testkey_rsa4096.pem \
--payload_extra_args \
"--signing_helper_with_files ./signing-helper.sh" \
foo.apex \
signed-foo.apex
Test: Run sign_target_files_apks.py on crosshatch target_files.zip.
Change-Id: I4b2422fd5cb1c60a3aa94511475e2a0e5b1666ca
Commit 7df64c3e starts to call common.LoadInfoDict() when generating
image archive, which reads additional files under BOOT/, RECOVERY/ and
ROOT/. Unzip everything from the target_files.zip.
Bug: 132456827
Test: Run img_from_target_files.py on previously failing
target_files.zip.
Change-Id: I22ee57c4f765bee9494478bf115b1581877401f4
The former comment no longer applies, as we have been always packing
META/file_contexts.bin in a target_files.zip (commit aa7318c3, since
Nougat), and we no longer look for the one under BOOT/RAMDISK/ (commit
d14b8956, since Q).
Test: N/A
Change-Id: I03f361234bf440e942f21e5a624862590248544b
This file is used by OTA generation so it needs to appear in mixed
builds with the combined content from the system and other versions of
the file.
Test: python -m unittest test_merge_target_files
Test: Running merge_target_files on a dynamic-partition-enabled build
and observing the resulting target files.
Bug: 131889742
Change-Id: I4ddbebc087e430f6307d0bd5461121a374e58ea4
Bug: 123428770
Test: Built system-only image and checked that no boot.img or
recovery.img files where created. Booted the resulting merged build on
device.
Change-Id: I760476502775e68125907c39e66b8665e789a798
The old process_file_contexts_bin function did not properly generate a usable
file_contexts.bin to regenerate images, so instead use the file_contexts.bin
from the other partial target files package. When combining any one of several
other partial target files packages with a single system partial target files
package, this file will properly apply contexts as long as the same source is
used for the system partial target files.
Test: Verify that file contexts are properlty applied to vendor image.
Bug: 131584454
Change-Id: I16f8cc3b7f2eb7f09746f0ddcb2c1daf3fd19da6
Some properties had 'test-keys' still set
after signing the target files zip for release.
These properties are now added to the RewriteProps
method.
Bug: 131810966
Test: manual
Test: `atest releasetools_test`
Change-Id: Ifb352ed28f5100f1e9f686d77e935723f7f6d3ae
common.GetCareMap() may return an empty list on unavailable care_map
since the change in commit 8bdfb990ea.
Caller needs to handle such a case accordingly. This CL fixes the caller
in add_img_to_target_files.py, and changes the return value to None to
break legacy callers loudly.
Fixes: 131794385
Test: `atest releasetools_test`
Change-Id: I7c94f456064199237e84ef75732bdd10ebe31736
When set, product-img-tag.zip contains super.img instead of individual
user images from target files. For virtual devices, super.img is needed
to boot the device, but individual user images aren't needed.
Test: on A/B DAP, with flag set:
- m updatepackage and look at img.zip
- img_from_target_files
both have super.img and not system / vendor / system_other
Test: on non-A/B DAP, with the flag set:
- m updatepackage and look at img.zip
- img_from_target_files
both have super.img and not system / vendor
Test: on A/B retrofit, with the flag set:
- m updatepackage and look at img.zip
- img_from_target_files
both have super_*.img and system_other.img, but not system / vendor
Bug: 113175337
Change-Id: I94e33091d0c837cae40776176b4dcfdd338aba90
When odm is changed, device manifest/matrices should be included.
When product is changed, framework manifest/matrices should be included.
Bug: 130714844
Bug: 126770403
Test: build with odm and product VINTF metadata
Change-Id: I49c8083e0e7185ae7b96047d68f1f624b1113dfc
