if BOARD_BUILD_SYSTEM_ROOT_IMAGE != true: # case A
- BOOT/RAMDISK corresponds to the / under normal boot, with matching
fs_config in META/boot_filesystem_config.txt.
- RECOVERY/RAMDISK corresponds to the / under recovery, with fs_config
in META/recovery_filesystem_config.txt.
else:
if BOARD_USES_RECOVERY_AS_BOOT == true: # case B
- ROOT/ corresponds to the / under normal boot, with fs_config in
META/root_filesystem_config.txt.
- BOOT/RAMDISK corresponds to the / under recovery, with fs_config
in META/boot_filesystem_config.txt.
else: # case C
- ROOT/ corresponds to the / under normal boot, with fs_config in
META/root_filesystem_config.txt.
- RECOVERY/RAMDISK corresponds to the / under recovery, with fs_config
in META/recovery_filesystem_config.txt.
- BOOT/RAMDISK doesn't exist.
This CL fixes case C, where we shouldn't try to generate
'META/boot_filesystem_config.txt' for BOOT/RAMDISK. It wouldn't be fatal
without this fix, but would wrongly scan the current directory and
include a large fs_config output into target-files.zip.
Bug: 72731506
Test: `lunch aosp_bullhead-userdebug` and `m dist`. (case A)
Test: `lunch aosp_marlin-userdebug` and `m dist`. (case B)
Test: Define 'BOARD_BUILD_SYSTEM_ROOT_IMAGE := true' for angler. `m
dist` and check the generated target-files.zip. (case C)
Change-Id: I5582ce8cca464d535af0718be0fd8e65791bd6c2
Also minor cleanups to make it pylint clean.
Test: Run check_target_files_signatures.py with a target-files.zip.
Test: pylint --rcfile=pylintrc check_target_files_signatures.py
Change-Id: Ife3b54c7805c2f2562e87e91ab4b4de355782012
In addition to the unzipping work, common.UnzipTemp() kindly bundles an
open ZipFile object as part of the return value. It doesn't look very
helpful to the callers though. It also looks less obvious that the
caller needs to properly close the handle (missing the close here is
benign though). This CL just removes the ZipFile object out of the
return value, and leaves the work to callers.
Test: `m dist` on both of A/B and non-A/B target.
Test: python -m unittest test_add_img_to_target_files
Test: python -m unittest test_common
Test: python -m unittest test_ota_from_target_files
Test: Check the callers to common.UnzipTemp() in code search.
Change-Id: Id47da3fd42a0e76d6ae8851f05780db319ee48cf
Typical failure case for boot image dex2oat is an inconsistent boot
classpath left over from incomplete build dependencies. Give advice
to run a top-level build.
Bug: 73749543
Test: m
Change-Id: I81c4ce9d02b2b360fe867b594d0a2b21c763e473
Factor out ANDROID_LOG_TAGS for boot image compilation. Do not use
the setting when ART_BOOT_IMAGE_EXTRA_ARGS is set.
Bug: 73749543
Test: m
Test: ART_BOOT_IMAGE_EXTRA_ARGS="--runtime-arg -verbose:verifier" m art-boot-image
Change-Id: Ia599381991f74f243fee966184715b0172742e78
I plan on turning the error on for APPS in AOSP soon, and in preparation for
that I'm introducing a finer granularity of warning/error control.
Also add an almost-empty whitelist, which will likely need to be expanded
in the future.
Bug: 73535841
Test: make
Change-Id: I2fc6700a504b7af50aa7bde727047bc56b167937
$(OUT_DIR)/target/product/$(TARGET_DEVICE)/lsdump_paths.txt will contain all
.lsdump paths relative to $(ANDROID_BUILD_TOP). This helps faster lookup while
running scripts to generate reference dumps.
Test: m -j findlsdumps for aosp_arm64_ab.
$OUT_DIR/lsdump_paths/generic_arm64_ab/paths.txt has paths to lsdump files
generated for the build.
Test: m -j findlsdumps for aosp_arm_ab.
$OUT_DIR/target/product/generic_arm_ab/lsump_paths.txt has paths to
lsdump files generated for the build.
Change-Id: Iab1640f57bf9d0af5e88e6dda64a610fedcbe87e
This should be the last case to be moved over.
Test: Generate an incremental BBOTA (which exercises the changed code).
Test: `rgrep mkdtemp` gives no more instance.
Change-Id: I76db069476201cdfaf3a2de9d9635dfe54507f7a
VTS checks for ro.product.board before running. Emulator does not have
that value and causes an exception.
So let's add it to the emulator and call it goldfish_$(TARGET_ARCH).
BUG: 73741117
Test: vts-tradefed run vts, should run the tests
Change-Id: I6b00f2923bc9609d4d05c45d47ceddd2bd7be091
Bug: 72552006
Test: Make a module with no source files,
run `m -j nothing`, notice that the error tells
which module has no sources
Change-Id: Ib169e7b3cb86d840a3acd644e42cd1f9f65e1304
... from the following functions in add_img_to_target_files.py.
AddSystem
AddSystemOther
AddVendor
AddProduct
AddDtbo
AddUserdata
AddVBMeta
AddPartitionTable
AddCache
The last user of the parameter in img_from_target_files.py has been
removed in commit 2bb109709a (in O).
Test: pylint --rcfile=pylintrc add_img_to_target_files.py
Test: Check all the callers to the above functions.
Test: m dist
Change-Id: I551d1683def8f8535062fc90f68dafa0f4252822
If there's a prebuilt with LOCAL_MULTILIB := true, but only a single
LOCAL_SRC_FILES entry, we end up with a weird build error where `cp`
is trying to copy the local directory. Exit early with an error in this
case.
Bug: 73904572
Test: build-aosp_marlin.ninja is identical
Change-Id: Ie2821817c237087a96e87fb9602e430e0f86584a
Instead of relying on whatever version of xmllint is on the host system,
build and use the version in external/libxml2.
Test: diff build_aosp-marlin.ninja, expected changes.
Test: m $(xmllint targets in build_aosp-marlin.ninja)
Test: introduce xml error, build fails
Change-Id: I39579f06db3777e3b5c8dda7c7541c25a35887b2
Some SoC vendors require firmware and persist directores to mount.
This must be provided in GSI for arm_ab not only for arm64_ab.
Once the directories are moved to /vendor, these policies for root
must be removed.
Bug: 36764215
Bug: 73720182
Test: GSI boot with 32bit devices
Change-Id: Ic5c6bb615c39853d51d233c00d2d9e8ee2c57802
The file has been removed from target-files.zip since commit
c19a8d5590 (Gingerbread), whose info has
been consolidated into META/misc_info.txt.
Test: `m dist`
Change-Id: Ic144457954f5742ea082dcd9ffbea71df4afe46e
Before this CL, the build could fail with error messages such as:
Error: out/target/common/obj/JAVA_LIBRARIES/core-oj_intermediates/classes.jar
contains class file jdk/internal/HotSpotIntrinsicCandidate.class, which is not
in the whitelist
This error message was only moderately helpful because it left a few
questions unanswered or misled ("Whitelist for what?", "Where does the
whitelist live?", "Is it a whitelist of class files or of packages?").
This CL clarifies that:
- it's a whitelist of packages allowed on the bootclasspath,
- where it lives (currently
build/make/core/tasks/check_boot_jars/package_whitelist.txt)
which makes the error message more actionable.
Test: manually checked that the error message now looks okay.
Bug: 17434570
Change-Id: I2f52a5e2eb532bc4945bedf9811de5857f67a9a3