We used to support getting idempotent images when given the same inputs,
by specifying UUID and AVB salt to the image builders. The support was
broken by Q changes that moved away from build-time fingerprints [1].
This CL addresses the issue by updating the logic in computing UUID and
AVB salt to be based on BuildInfo.fingerprint, as opposed to the
deprecated static build fingerprint.
[1] https://android-review.googlesource.com/c/platform/build/+/892933
Bug: 134525174
Test: TreeHugger
Test: lunch a target; `atest --host releasetools_test releasetools_py3_test`
Test: `m dist`; `unzip out/dist/target_files.zip IMAGES/\*`;
`zip -d out/dist/target_files.zip IMAGES/\*`
Test: `add_img_to_target_files -a out/dist/target_files.zip`. Verify that
the rebuilt images are identical to the ones deleted.
Change-Id: I8844fc7f044e9abfcd96a00e8958fa0583c70eaf
First, remove the use of info_dict['fstab'] in add_img_to_target_files.
- info_dict['fstab'] corresponds to recovery fstab
(`/etc/recovery.fstab`), which may differ from the one used for
normal boot.
- When calling build_image.ImagePropFromGlobalDict, we already have the
desired info from global dict (`META/info_dict.txt`).
Second, common.LoadInfoDict now loads recovery fstab only for non-A/B
devices. Because the info is only meaningful for installing non-A/B OTAs
(under recovery mode).
Fixes: 132458722
Test: TreeHugger
Test: Build non-A/B incremental OTAs.
Change-Id: Id23e7b17264c123319fe00b1663d52bfd9b4a5e2
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This change includes the platform build system and release tools changes to
move the recovery resources from system to vendor (or /system/vendor). The
release tools need to know where to generate the recovery patch, and they
discover this from misc_info.txt variable board_uses_vendorimage, which the
platform build system generates.
We remove applypatch from PRODUCT_PACKAGES, but it is added back as a required
module in target/product/base_vendor.mk.
Several release tools rely on the misc_info.txt board_uses_vendorimage variable
to know how to generate and detect the recovery patch.
This change partially removes the --rebuild_recovery flag from the
merge_target_files.py script. The flag will be fully removed in a follow-on
change.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: Ia4045bd67ffb3d899efa8d20dab4c4299b87ee5f
The vendor_boot partition is generated by mkbootimg and contains all the
device-specific information that used to reside in the boot partition.
Bug: 137297791
Change-Id: I5b005097b73f59857c3a2f92d693b3e67ee8424e
Bug: 137853921
Bug: 138671115
Test: python -m unittest test_common
Test: python -m unittest test_add_img_to_target_files
Test: Ran 'merge_builds --build_vbmeta' for two devices, one with the
vbmeta struct on system.img and another with vbmeta_system.img. Flashed
the regenerated vbmeta.img files on devices, devices boot.
Change-Id: I8d7585c7af468be3d242d8aceeed6d27e6fc6d96
It used to be packed at IMAGES/recovery-two-step.img, but to serve OTA
purpose only.
Test: `m dist` with a non-A/B target. Check the file in the generated
target_files.zip.
Test: Create two-step package. Check that recovery-two-step.img is used.
Change-Id: Iec6a73c682e0f844cd8c0b758c9470fa35dd15d8
This CL changes the condition for building super_empty.img from
PRODUCT_BUILD_SUPER_PARTITION to PRODUCT_USE_DYNAMIC_PARTITIONS, as a
follow-up to the change in [1].
With the CL in [1], it skips building super.img and super_empty.img both
when turning off PRODUCT_BUILD_SUPER_PARTITION. However, the latter
should be mandatory whenever dynamic partitions is enabled. Because
fastboot relies on this file to properly flash dynamic partitions. Plus,
the cost for building super_empty.img is much lower than the one for
super.img.
As part of the change, it'll write group info into target_files when
building with PRODUCT_BUILD_SUPER_PARTITION == false. It's the work for
target_files merging script to determine the values to be picked up. The
current logic in merge_target_files.py always uses the one from vendor
target_files. This CL adds a testcase to ensure the behavior.
[1] https://android-review.googlesource.com/c/platform/build/+/928756
Bug: 135752763
Test: `m dist` with a target that sets PRODUCT_BUILD_SUPER_PARTITION to
false. Check the built artifacts contain super_empty.img. Verify
that the build can be flashed properly.
Change-Id: I277f087eab45663a6c3b33333d16e9e576c1c25c
common.AVB_VBMETA_PARTITIONS was recently added (commit
08c190fc89) for the same purpose.
Test: TreeHugger
Change-Id: I65572d54c22a753fdef80677377fcc9b684ee16f
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
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
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
Test: `atest --host releasetools_test`
Test: `m dist` with a target that uses non-sparse images.
Test: Run UpdateVerifierTest on blueline.
Change-Id: I8fdebee42fcaac78c2d1be2a84ddb69f46ec701d
OTA tools should pick up the avbtool, as listed in dict['avb_avbtool'],
from the current PATH (plus bin/ under the dir specified via `--path`),
the same way as handling all other host tools.
Test: `m dist`
Change-Id: I3eb4d2c61979b03d9c23b2403d9a38cf052d87ea
Also makes AddSystem check that an output_zip exists before attempting
to add the recovery patch to the output zip.
Bug: 128838154
Test: Running merge_target_files with --rebuild_recovery and verifying
it passes --rebuild_recovery to add_img_to_target_files.
Change-Id: I19347b2c0dabf29b7196045b18551b5d0687df2c
tools/releasetools/add_img_to_target_files.py: This patch excludes the
inclusion of the system path into the target files if it does not exist (which
it will not if we are not building the system image).
Bug: 123430711
Test: Disable building system image, verify that target files builds without system.
Change-Id: Iaf964ede2b1df5ea4e004b572fd91187a366e75e
We used to create the intermediate output file as a tempfile, when
adding images to a given zip file. This CL changes OutputFile to write
intermediate files under the given input dir (i.e. OPTIONS.input_tmp
that holds the unzipped files), if the final destination is a zip
archive. This allows image building codes finding the generated images
at consistent locations. The intermediate files will be cleaned up as
part of OPTIONS.input_tmp.
Bug: 122608028
Test: `m dist`
Test: Delete OTA/super*.img from a target_files.zip. Run
`add_img_to_target_files.py -a` that re-generates split super
images.
Change-Id: I97903a59fcc0ca5e43bb9b07c3a0b25e9baa92f9
We used to build retrofit full OTA package as long as
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS is true. This doesn't work with AOSP
targets that have the flag set but without any available vendor image.
This CL detects such a condition and uses a separate flag to guard the
retrofit OTA building as well as the split super images generation.
Bug: 120852744
Test: `m -j dist` on blueline (w/ vendor images) and aosp_blueline (w/o
vendor images).
Change-Id: I65726f24f8fc546be6802941a6a06590a3804c16
For some internal branches, vendor.img isn't built, so there
is no need to build super image / super split images there.
Test: remove vendor.img and VENDOR/ from target_files_intermediates, then
run add_img_to_target_files
Fixes: 120634805
Change-Id: I2834a27ce232538f203733c204dd257279c789fc
Use the new script to build super_empty and super split images. No more
transformation to lpmake_args.
Test: build target_files_package for retrofit device
Change-Id: Id5f6bd607654ca869bcdf58d86b7ae300e3927eb
Chained vbmeta images should be included into the top-level vbmeta.img
as chained partitions. It's done in the path of `m`, but not `m dist`.
Bug: 118115607
Test: `m dist` a target that uses chained vbmeta.
a) Check that the `vbmeta.img` in target-img.zip contains the image
descriptor of `vbmeta_system.img` (`avbtool info_image`).
b) `avbtool verify_image --image vbmeta.img \
--expected_chain_partition \
vbmeta_system:1:/path/to/vbmeta_system/pubkey`
c) `avbtool verify_image --image vbmeta_system.img`
Change-Id: I064e583b247c44b9b2f19355838550bb5dbb8f26
Converts the following files to Python logging.
add_img_to_target_files.py
blockimgdiff.py
build_image.py
check_ota_package_signature.py
common.py
img_from_target_files.py
make_recovery_patch.py
ota_from_target_files.py
sparse_img.py
verity_utils.py
This separates logging outputs from normal outputs, and allows easier
switching between different verbosity levels. It also supports adjusting
logging config via environment variable (LOGGING_CONFIG).
Test: `m dist`
Test: `python -m unittest discover build/make/tools/releasetools`
Change-Id: Idfc3f7aff83e03f41f3c9b5067d64fd595d5192d
stdout and stderr will default to subprocess.PIPE and subprocess.STDOUT
respectively (which is the expected behavior from most of the existing
callers), unless caller specifies any of them.
Test: `m dist`
Test: python -m unittest \
test_common \
test_add_img_to_target_files \
test_ota_from_target_files \
test_validate_target_files
Change-Id: I43b3f08edfa8a9bcfe54baf9848dc705c048e327
The image building functions in build_image.py have been returning
(success, result) or special values to indicate the validity of the
result. The same logic can be better expressed by raising exceptions
instead, because
a) using a special value relies on caller to check for that magic
value;
b) exceptions can carry additional messages other than a boolean does,
e.g. the output from the failing command;
c) caller can have cleaner code flow without explicitly checking for
the validity of the result.
This CL changes such functions to raise on errors. The majority of these
functions are internal to build_image.py only, except for BuildImage()
that has a few callers in add_img_to_target_files.py (which all die upon
error anyway).
Test: `m dist`
Test: python -m unittest test_build_image
Test: python -m unittest test_add_img_to_target_files
Test: python -m unittest test_validate_target_files
Test: Inject an error to the depended binaries (e.g. avbtool), and check
that build_image.py exits with error messages.
Change-Id: Ibe4d51e267756bb1a00fa9238a213f9d55fd9b58
Unless using dynamic partitions, `partition_size` should be a fixed
value that equals to the partition size in BoardConfig. It should stay
the same when building an image for that partition. Only the actual
image size that's used to hold the filesystem could be adjusted. This CL
cleans up the uses of `partition_size` and `image_size` to better
reflect such logic.
With dynamic partitions, the only thing that changes is the need to
compute `partition_size` upfront. Once that's done, `partition_size`
should remain unchanged.
Test: `m dist`
Test: `python -m unittest test_add_img_to_target_files`
Test: `python -m unittest test_validate_target_files`
Change-Id: Idedb3e018c95e8f63dc4d9c423be27f30ebb584f
Reads the fingerprint of a partition from the build props and embeds it
into the care_map. Later, the update_verifier will compare the
fingerprint before it performs the verification.
Bug: 114778109
Test: generate care_map for sailfish and new pixel
Change-Id: I06afa01bf6dd3de4456a08ee7960954facc775fb
The new suffix distinguishes the new care_map from the ones in plain
text format; and thus the old update_verifier won't report an error
upon parsing failures.
Bug: 115740187
Test: Generate OTA files for Pixels
Change-Id: Ia782afd8cbb0f4bb8c363edaa00e92ab302d5d1b
Bug: 112007947
Test: `m dist` with aosp_taimen-userdebug.
Test: Set up a target that uses chained VBMeta images of
`vbmeta_mainline` and `vbmeta_vendor`. `m dist` and check the
build log, as well as outputs from
`avbtool info_image --image vbmeta.img`,
`avbtool info_image --image vbmeta_mainline.img`,
`avbtool info_image --image vbmeta_vendor.img`.
Change-Id: Ib1d4e97f583b65245703eae15d211adcd9e83741
super_empty.img is needed for "fastboot update" to work, as such, it
must be included in the update package. This change adds lpmake
parameters to misc_info.txt for add_img_to_target_files.py, and ensures
that lpmake is packaged with otatools.zip.
The build-superimage-target macro is now split into two functions - one
to generate the device-specific arguments, and another to build the full
command-line for convenience. The former is used to pass arguments
directly to add_img_to_target_files.
Bug: 113524256
Test: make updatepackage builds and includes super_empty.img
make otatools includes lpmake
Change-Id: I25091c964b036beeea2a8b8f738e2c18937c1eb4
It used to accept a non-None input_dir to indicate the need to
re-generate images (called from add_img_to_target_files.py). During that
flow, both of the two parameters redundantly refer to the same input
dir. This CL replaces the second parameter with a bool value instead.
Test: `python -m unittest test_common`
Test: `m dist` with aosp_taimen-userdebug
Test: `zip -d aosp_taimen-target_files-eng.zip IMAGES/\* &&
add_img_to_target_files.py -a aosp_taimen-target_files-eng.zip`
Change-Id: I0a5a164366acb116407f94bb350872a3a0b207d1
Otherwise it gives a floating-point value (i.e. 1230768000.0). e2fsdroid
(i.e. the user of the value) didn't complain though, because it calls
strtoul(3) without checking endptr.
Bug: 80600931
Test: `m dist` with aosp_taimen-userdebug, check the build log.
Change-Id: I7467a60c947134b42f079c7a57fb8a9a9d4277da
Attempting to reduce the number of different spellings we have for
"product services" partition in the codebase.
Bug: 112431447
Test: m
Change-Id: I6debd3f5f5abc4bd1e22f2ef11c5fe131915976c
Merged-In: I6debd3f5f5abc4bd1e22f2ef11c5fe131915976c
Call the host binary care_map_generator to generate the care_map in
protobuf format. The parsing part of proto messages has already been
supported in the update_verifier.
Bug: 77867897
Test: unittests pass; run add_image_to_target_files
Change-Id: I40d3184b4b5c48a6dd55203afc84cca73d5765e9
Attempting to reduce the number of different spellings we have for
"product-services" in the codebase.
Bug: 112431447
Test: m
Change-Id: Iec531122297cf4b86ff8601732d4ab7ccf5c2183
The add_img_to_target_files.py script uses upper() to determine
the name of sub-directory under target_files_intermediates. The
name of the image is product-services.img but the sub-directory
name was PRODUCT_SERVICES. Change it to PRODUCT-SERVICES so that
'm dist' works.
Test: m dist
Change-Id: I8cad841c674b5d62c1d803d0383fc3aee14f272a
