Split merge_target_files function into several steps, so we can increate
readability and add conditional flows for other *SSI mixed build with less effort
Test: m -j & atest passed
Change-Id: I558f9dd5bca31b132a09cb36d9dfcd30c92efbc9
When we build the system image separately from the vendor image, we need the
/vendor/odm link (if any) to be created in the vendor build, not the system
build. This change moves the create-vendor-odm-symlink function outside the
BUILDING_SYSTEM_IMAGE gaurd, and inside the BUILDING_VENDOR_IMAGE gaurd.
Bug: 136516335
Test: Build vendor image, verify that /vendor/odm -> /odm
Change-Id: I6edf5d6d1fa0b2f632f67113f69a49b43f719941
This CL changes the condition for building super_empty.img from
PRODUCT_BUILD_SUPER_PARTITION to PRODUCT_USE_DYNAMIC_PARTITIONS, as a
follow-up to the change in [1].
With the CL in [1], it skips building super.img and super_empty.img both
when turning off PRODUCT_BUILD_SUPER_PARTITION. However, the latter
should be mandatory whenever dynamic partitions is enabled. Because
fastboot relies on this file to properly flash dynamic partitions. Plus,
the cost for building super_empty.img is much lower than the one for
super.img.
As part of the change, it'll write group info into target_files when
building with PRODUCT_BUILD_SUPER_PARTITION == false. It's the work for
target_files merging script to determine the values to be picked up. The
current logic in merge_target_files.py always uses the one from vendor
target_files. This CL adds a testcase to ensure the behavior.
[1] https://android-review.googlesource.com/c/platform/build/+/928756
Bug: 135752763
Test: `m dist` with a target that sets PRODUCT_BUILD_SUPER_PARTITION to
false. Check the built artifacts contain super_empty.img. Verify
that the build can be flashed properly.
Change-Id: I277f087eab45663a6c3b33333d16e9e576c1c25c
This file is used to check that each interface in an init_rc file is a
known hidl_interface.
Test: Adding a misspelling to an init_rc's interface line and observing
build failure.
Bug: 77646540
Change-Id: I30c2dff29679b95085b5c76f6d68e4d794f965e9
This location allows the agent to be attached to arbitrary processes.
It only makes sense to include libdumpcoverage.so on coverage builds,
as these are the only builds that have any information to be dumped.
Test: manual, used examples in README (see other CL) to test whether
it works on a userdebug_coverage build on cuttlefish
Change-Id: Ib2fece1b41a3b5d16c8a2a444c5486137e475fda
This allows a consistent logic in using the avbtool which could be
board-specific.
Test: `atest releasetools_test`
Test: Run sign_target_files_apks.py on a target_files.zip.
Change-Id: I8cd93b8e71146985734f85c31f4662f5e2e9534c
This ensures a matching interface between sign_apex and apex_utils.
The test apex `testdata/foo.apex` is generated by running
`system/apex/apexer/runtests.sh`.
Test: python -m unittest test_sign_apex
Test: atest releasetools_test
Change-Id: I7c14b1df2a3038ad206aa3e5aac084c47baaa00b
Build support exists to copy a set of kernel modules to the recovery,
vendor, and odm images. Extend similar support for copying kernel
modules to the ramdisk via BOARD_RAMDISK_KERNEL_MODULES. If
BOARD_USES_RECOVERY_AS_BOOT, then BOARD_RAMDISK_KERNEL_MODULES is
added to the set of modules to be copied to recovery.
Libmodprobe now supports reading a list of kernel modules to be loaded.
Enable the creation of modules.load and modules.load.recovery files.
These files contain the contents of
BOARD_[RAMDISK|VENDOR|ODM|RECOVERY]_KERNEL_MODULES_LOAD, or if those
variables are not set, the contents of
BOARD_[RAMDISK|VENDOR|ODM|RECOVERY]_KERNEL_MODULES (indicating all
modules should be loaded by default). This allows for
optional customization of the set of modules to be loaded by
libmodprobe and the order they are loaded in.
Bug: 130585369
Change-Id: I9340787d31d71aebc8552344675d9696c189a8a1
It is now set on the /product partition by relevant devices.
Bug: 135569569
Test: lunch mainline_system_arm64; inspect system/etc/prop.default
Change-Id: I34696977f584a65741c6002e6688d86e66a1f121
There are some places defining same file open function and use
common.LoadDictionaryFromLines. This commit creates
LoadDictionaryFromFile to reduce some code redundancy.
Test: m -j & atest passed
Change-Id: I6a3fa48693095937f8c79ce6f3c110b6862a1967
This variable was accidentally changed to refer to the
shorthand PRODUCT_XYZ instead of PRODUCTS.<mk>.PRODUCT_XYZ
in a previous mass-migration, but that shorthand didn't
exist for these variables. Add it in.
Also whitelist the offender introduced since it was broken.
Test: lunch generic; m nothing
Change-Id: I29dd73c29796743e770afa0c2ceb4f8583dc6e1e
- `--block` has been a no-op since Oreo [1] -- ota_from_target_files
will always build block-based OTAs or A/B OTAs.
- MKBOOTIMG is no longer needed when calling ota_from_target_files, at
least for the callsite in Makefile. Because target_files.zip has been
including boot/recovery images since Lollipop [2].
This CL also switches to long options to improve readability.
[1] commit 457cbf6a8a
[2] commit 3c84f56948
Test: TreeHugger
Change-Id: I801bd0525d2529156bbf783698661d90ba24017a
In order to get a Python 2 and 3 compatible re-raise behavior, this CL
removes the stack traceback for the lines within apex_util module (i.e.
sys.exc_info()[2]). It's not a big loss in practice, since we only have
one line within the try-except block (`common.RunAndCheckOutput()`)
that's no longer reported in the traceback.
Using `six` module could better solve this, but only after building
releasetools as python_binary_host modules where we can properly handle
the module dependency.
Bug: 131631303
Test: TreeHugger
Test: `python -m unittest test_apex_utils`
Test: `python3 -m unittest test_apex_utils`
Change-Id: I0c5a72ec9fad5ff9d8c9c94d29e813e433ec2921
