summaryrefslogtreecommitdiff
path: root/tools/warn/java_warn_patterns.py
diff options
context:
space:
mode:
author Tao Bao <tbao@google.com> 2019-06-04 16:26:45 -0700
committer Tao Bao <tbao@google.com> 2019-06-04 22:44:45 -0700
commit4978fa99d17de70b09472a4c41c8fe610364fbbb (patch)
tree325407ac75730e8d7fc840df83b7a0ac9a355d96 /tools/warn/java_warn_patterns.py
parentec2772d2be6347e9f01fa1364938e70d09cc921a (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