diff options
| author | 2019-06-04 16:26:45 -0700 | |
|---|---|---|
| committer | 2019-06-04 22:44:45 -0700 | |
| commit | 4978fa99d17de70b09472a4c41c8fe610364fbbb (patch) | |
| tree | 325407ac75730e8d7fc840df83b7a0ac9a355d96 /tools/warn/java_warn_patterns.py | |
| parent | ec2772d2be6347e9f01fa1364938e70d09cc921a (diff) | |
Rebuild recovery-from-boot patch when calling add_img_to_target_files.
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
Diffstat (limited to 'tools/warn/java_warn_patterns.py')
0 files changed, 0 insertions, 0 deletions