This prop is owned by OEM, OEM can set this if they want to disable
VABC.
Test: m dist, make sure generated OTA has VABC disabled
Bug: 185400304
Change-Id: Iceb2fb1f399d38a51722352a86ddf68af05fa24e
INTERNAL_VENDOR_BOOTCONFIG_TARGET is a required dependency of
target-files-package so it can be built from a clean build.
Test: rm -rf out/target/product && m target-files-package
Bug: 190329824
Change-Id: I9873aee3c9fb303d2ad245b5433d13eb76ab55f9
In the case of unbundled build, the module in vendor should use
system(_ext) module by prebuilt one. But RRO depends on system module
directly depending on some conditions(packages exporting resources)
In this change,
1. Temporarily make LOCAL_RES_LIBRARIES empty(For now, auto generated
RRO doesn't use overlaid package's resources), enable it when prebuilts
are ready.
2. According to (1), its SDK_VERSION can be current)
Bug: 187404676
Test: TARGET_BUILD_UNBUNDLED_IMAGE m vendorimage, and check if there is
no build error regarding RRO.
Change-Id: I94e3122372dd20c942b2c858070a6ca797312792
Use PLATFORM_VERSION_ALL_CODENAMES to construct PLATFORM_SYSTEMSDK_VERSIONS
so that both S and T are accepted while T is active but S is not finalized.
Bug: 186121492
Test: treehugger
Change-Id: Ia9f58c5986c717cb2882e2fc4daadb2b3874c6b5
Disable the generation of .config file when the variable
LOCAL_DISABLE_TEST_CONFIG is true.
Bug: 188927912
Test: rum 'm module-name' (`android_test_helper_app` type module)
Test: TreeHugger
Change-Id: I64372b4ba84fcf1af937abdee345ceb1d3c2f6c5
VTS and some other tests would replace the system images with GSI. To
put the correct fingerprint in the test report, we need to know if the
new fingerprint format is in use. So, add a vendor build prop.
OEMs are reponsible for setting this build prop, or using other ways
to put the correct fingerprint in the test report.
Bug: 188824341
Test: boot the device, check build prop
Change-Id: I6bc7f01903865fc2c256d209debdab68cd9d1bb3
make.
Avoids TARGET_FLATTEN_APEX lying about it, so we can trust it in
scripts, e.g. in art/build/apex/runtests.sh.
Test: banchan com.android.art; art/build/apex/runtests.sh
Bug: 179900989
Change-Id: I5d3226047e51a51ee76de2cbfad050e200568655
BUILD_HOST_EXECUTABLE modules are substantially deprecated, but some
partners are still using them for their bits with the workaround
provided in the product definition. This fixes a build error where
the host module doesn't have a linkable ELF note archive.
MTE is not intended for host modules, and it's fine for us to say
"host module using AndroidMk - no MTE for you" if this changes.
Test: Manually tested using a BUILD_HOST_EXECUTABLE module.
Change-Id: Ifedff39f2f03c08bfb644221d2ab1b88e635c8a3
Devices using GKI architecture will use a prebuilt boot.img.
However, we should still sign this prebuilt boot.img with
device-specific AVB keys.
Steps to test the CL.
1. In a device BoardConfig.mk:
# Uses a prebuilt boot.img
TARGET_NO_KERNEL := true
BOARD_PREBUILT_BOOTIMAGE := device/google/redbull/boot.img
# Enable chained vbmeta for the boot image.
# The following can be absent, where the hash descriptor of the
# 'boot' partition will be stored then signed in vbmeta.img instead.
BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2
2. `make bootimage`, then `avbtool info_image --image $OUT/boot.img`,
checks the image is re-signed with a device-specific key
3. `make dist` to generate out/dist/TF.zip
4. `unzip out/dist/TF.zip IMAGES/boot.img`
5. `avbtool info_image --image out/dist/IMAGES/boot.img`,
checks the image is re-signed with a device-specific key
6. `sign_target_files_apks \
--avb_boot_key=external/avb/test/data/testkey_rsa8192.pem \
--avb_boot_algorithm=SHA256_RSA8192 \
--avb_boot_extra_args="--prop test:sign" \
./out/dist/*-target_files-eng.*.zip signed.zip`, resign the TF.zip
7. `unzip signed.zip IMAGES/boot.img`, then use `avbtool info_image` to
check the boot.img is re-signed with the --avb_boot_key in step 6.
Bug: 188485657
Test: above steps
Change-Id: I7ee8b3ffe6a86aaca34bbb7a8898a97b3f8bd801
Starting from Android 10, the system.img layout consists of
$TARGET_SYSTEM_OUT and $TARGET_ROOT_OUT, and is mounted by the
init as root. That is, system.img is always created as if
BOARD_BUILD_SYSTEM_ROOT_IMAGE was set.
https://source.android.com/devices/bootloader/partitions/system-as-root
The previous concern is that there might be compatibility issues between
the ramdisk contained in boot.img with a newer system.img. But this is
no longer an issue after we always mount the system.img as root.
Bug: 187157581
Test: Tree Hugger
Change-Id: I4537e6ce6fb39b4b86caac82a13716abf515ffd6
