We sometimes see build failures when building platform.zip happens
at the same time as building vendor.img if the vendor.img rule
runs rm -rf $OUT/vendor/lib/modules at the same time that platform.zip
is zipping $OUT/vendor/. Move the kernel modules into normal
installation rules so that they are in place by the time either
the vendor.img or platform.zip rules run.
This will also cause the kernel modules to show up in
installed-files*.txt.
Test: m vendorimage && ls $OUT/vendor/lib/modules
Change-Id: I178b1d54bfcdb5cf5c29885ace9183ac28fc8826
am: 97a6690a23 -s ours
am skip reason: change_id I5859e30be63bfd54398cf41fd2d907f15285f560 with SHA1 4978fa99d1 is in history
Change-Id: I4f5c95a89573d94c8bc1e7f642ce24990b591cc6
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
Merged-In: I5859e30be63bfd54398cf41fd2d907f15285f560
(cherry picked from commit 4978fa99d1)
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
Include misc_info.txt (of CF's super.img) in *-img-*.zip.
This is needed if we want to rebuild super.img by replacing
some partitions in it.
Other tools, lpunpack and lpmake, are included in CF's
host package in another CL.
Bug: 134461288
Test: $ lunch aosp_cf_x86-userdebug
$ m dist
$ unzip -l $OUT/*-img-*.zip | grep misc_info
619 2019-05-27 17:42 misc_info.txt
Change-Id: Idf6146c2a7f9f32c9c4e5ddd2f6b9e65fc6bf55b
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)
"OUT" means "out/target/proudct/<product>/".
But "OUT_DIR" means "out/".
So we can't use "OUT_DIR" instead of "OUT".
We can use "PRODUCT_OUT" instead of "OUT" which means same folder.
Test: N/A Just document modification
Change-Id: Id08664ba48b226ead7ab6b00d0291259d3a737ba
This reverts commit 6c77a6baa6.
Reason for revert: aog/974065 fixes the problem that caused the revert
Change-Id: I935f78762b23ac63a79a9529515ff4ef394d5c3c
Strip bitness information for PRODUCT_PACKAGES and
PRODUCT_HOST_PACKAGES before checking against ALL_MODULES.
Also correct spelling: nonexistant -> nonexistent
Bug:
If PRODUCT_ENFORCE_PACKAGES_EXIST was set, the build system would
complain about nonexistent packages for e.g. HALs where the bitness was
specified using a suffix, such as android.hardware.audio@4.0-impl:32
Test:
Add android.hardware.audio@4.0-impl:32 to PRODUCT_PACKAGES, specify
PRODUCT_ENFORCE_PACKAGES_EXIST, ensure no whilelist is set.
"make systemimage vendorimage" -> No error.
Signed-off-by: Felix <google@ix5.org>
Change-Id: Id59460a19320aa9437b8805411a0d97fa6432633
Alistair Strachan