These were found when trying to run remotely on RBE with only the
sources depended upon available for each rule.
Bug: 130111713
Test: treehugger
Change-Id: Id763f8fc7dfbe60445f98604db3422147165f537
BOARD_SUPER_PARTITION_WARN_LIMIT can be set by OEMs to print
a warning when the sum of sizes of logical partitions exceed the same.
It is set to 95% of BOARD_SUPER_PARTITION_SIZE by default.
Bug: 133329143
Test: mmm -j32
Change-Id: I7d3bedd970a92be60991898e436f63d914359301
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
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)
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
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
