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
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
For VAB launched device, factory OTA will write system_other
partition to the super image. So we want to check that
sum(dynamic partitions) + system_other + overhead <= super at
build time.
Since we don't know the overhead at build time, we might instead
check sum(all partitions) < super.
Bug: 185809374
Test: m check-all-partition-sizes, unittests
Change-Id: Ia7ba5999d23924a1927e9a9463856a4d0ea90c20
Currently the debug ramdisk resources might be under / or
/first_stage_ramdisk of the ramdisk, and is determined by
some BOARD variables, e.g., BOARD_USES_RECOVERY_AS_BOOT,
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT, etc.
To make a generic boot-debug.img that can work on both devices,
let's move the debug resources always under / of the ramdisk.
Bug: 186082603
Test: boot a device with boot-debug.img
Test: boot a device with vendor_boot-debug.img
Change-Id: I55dc8ff322f6b97e2d6dc1a4ee5935e863f2f835
To dexpreopt in post processing, store config files for dexpreopt
Bug: 158843648
Test: m dist and check dexpreopt_config.zip
Change-Id: I5c63a5ffc10023994b14e3a63f50defb9194739f
aosp/1664081 introduces a bug where if BOARD_VENDOR_RAMDISK_FRAGMENTS is
empty, then INTERNAL_VENDOR_RAMDISK_FRAGMENTS would become " " (single
whitespace).
Just unconditionally $(strip ...) the variable to remove any extra
whitespace.
Bug: 183395459
Test: m dist and check *-target_files-*.zip
Change-Id: Ic842756f3a64c073593592d22c980820664e11c1
If BOARD_BOOT_HEADER_VERSION >= 4,
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT is true and
BOARD_INCLUDE_RECOVERY_RAMDISK_IN_VENDOR_BOOT is true, then build
recovery as a standalone ramdisk fragment in vendor_boot image.
The recovery ramdisk would be a vendor ramdisk fragment packaged in
vendor_boot, whose ramdisk_name is "recovery" and ramdisk_type is
"VENDOR_RAMDISK_TYPE_RECOVERY".
Bootloader can omit loading the recovery ramdisk during normal boot to
optimize the size of the initramfs.
Bug: 183395459
Test: Presubmit
Test: Modify BoardConfig of CF and m dist. Verify the vendor_boot.img
with unpack_bootimg.
Test: Strip the vendor_boot of the recovery ramdisk, and verify that CF
can boot to normal boot without the recovery ramdisk.
Change-Id: I6e9a2781ec87aece10d4844fa18bbe9a7b4674e6
Package jacoco-report-classes.jar, proguard_usage.zip and
proguard_dictionary out of directories in $OUT/obj/PACKAGING
so that they get cleared by m installclean. This will make
incremental builds that package these files accurate as long
as installclean was run, which is much faster than a full clean
build.
Bug: 184583915
Test: m TARGET_BUILD_APPS=DeskClock EMMA_INSTRUMENT=true dist
Change-Id: I60c6a0fec1fbce26eab8d5adab25a2231b48e251
Similar to commit Ic887ea93d4c5181eca0f82c3cdf3ce3b72f4c185
for boot-debug.img, we should also only build boot-test-harness.img
if boot.img exists.
Bug: 184365242
Test: tree hugger
Change-Id: Ie0d9e460905d488e418cf4ee1bd44e6e7c58470d
Usage:
```
BOARD_(VENDOR|VENDOR_RAMDISK)_KERNEL_MODULES_OPTIONS_FILE(_ver) := \
$(wildcard <path of modules.options in source tree>)
```
Then the modules.options would be installed as
(vendor_dlkm|vendor_ramdisk)/lib/modules/(ver/)modules.options.
Also fix bug where the kernel version subdir is missing when generating
modules.blocklists file.
Bug: 182417593
Bug: 184238876
Test: Create a options file with incorrect syntax, verify build fails
Test: Verify the new macro indeed installs the options file
Change-Id: I7ba56e9dd8d73055bc276446c385a8d79080c2a6
Add more checks around BOARD_BOOT_HEADER_VERSION in board_config.mk.
Refactor generation logic of vendor_boot ramdisk fragments.
Consolidate initialization and validation check to its own section.
Adjust some variable names and initialization sequence so the follow-up
change can land more cleanly.
Rename variable name "dir" so that it don't collide with the Makefile
function "$(dir ...)".
Bug: 183395459
Test: Presubmit; Change should be no-op with respect to build artifacts.
Test: Modify BoardConfig of CF and m dist. Verify the vendor_boot.img
with unpack_bootimg.
Change-Id: I8785c40dd9f87f3797a56ada93e65939d27d0e9b
If a build has PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
set (which is set for P+ builds) but no kernel is built,
the original code emits a warning, but it won't be able
to build target files package because it depends on
kernel_configs.txt and kernel_version.txt without any rules.
Properly clear BUILT_KERNEL_CONFIGS_FILE and BUILT_KERNEL_VERSION_FILE
so that it won't be depended on in this case.
Bug: 184128489
Test: TH + forrest
Change-Id: I4b8fbd117f114555cf606e3c3b48eb564dbe786b
This reverts commit ccfea17fb7.
Reason for revert: Original bug was resolved by updating branch config
Change-Id: I2327092261a2147fa8f2be3d878db04228e65511
This change doesn't change the condition for building super_empty.img,
it just add a toggle PRODUCT_BUILD_SUPER_EMPTY_IMAGE that product
makefiles can use to skip building super_empty.img.
Products that don't use super_empty at all, for example GSI, can set
this option to ensure the super_empty.img is not built.
Bug: 183068624
Test: "m dist" on GSI and check the build artifacts under OUT and DIST
directories, and check the contents of *-img-*.zip
Change-Id: I54943952873d2d297fd9d18cbe14742bc12ae9c6
If system and vendor are built separately, none of the two
builds contained kernel information. The process of extracting
kernel information shouldn't depend on system and vendor
builds, but on the existance of the kernel image.
With this change, one of system or vendor build may have
INSTALLED_KERNEL_IMAGE defined and the other has
PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS defined. The one
with INSTALLED_KERNEL_IMAGE defined will contain kernel information
in target files.
After target files are merged, check_target_files_vintf will kick
in to do the checks properly.
Test: forrest
Bug: 180475190
Change-Id: I8d887dd94e1171ab277f02f25534caf098e3faae
Commit I9967d06bde0e18a12b84b5b0b568db09765fe305 supports adding a
generic boot_signature into boot.img v4. This change allows replacing
the boot_signture signing key with a release key during the release
process.
The default GKI signing key can be specified in a BoardConfig.mk via:
BOARD_GKI_SIGNING_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_GKI_SIGNING_ALGORITHM := SHA256_RSA2048
BOARD_GKI_SIGNING_SIGNATURE_ARGS := --prop foo:bar
The release signing key/algorithm can be specified by the following options
when invoking sign_target_files_apks:
--gki_signing_key=external/avb/test/data/testkey_rsa4096.pem
--gki_signing_algorithm=SHA256_RSA4096
Additional arguments for generating the GKI signature can be
specified as below:
--gki_signing_extra_args="--prop gki:prop1 --prop gki:prop2"
Bug: 177862434
Test: make dist
Test: sign_target_files_apks \
--gki_signing_key=external/avb/test/data/testkey_rsa4096.pem \
--gki_signing_algorithm=SHA256_RSA4096 \
--gki_signing_extra_args="--prop gki:prop1 --prop gki:prop2" \
./out/dist/*-target_files-eng.*.zip signed.zip
Test: Checks GKI boot_signature is expected after signing:
`unzip signed.zip IMAGES/boot.img`
`unpack_bootimg --boot_img IMAGES/boot.img --out unpack`
`avbtool info_image --image unpack/boot_signature`
Test: unit test: releasetools_test and releasetools_py3_test
Change-Id: I61dadbc242360e4cab3dc70295931b4a5b9422a9
When building images in -without-vendor clients, we need to filter out:
vendor, vendor_dlkm, odm, odm_dlkm
from the dynamic partitions list for the OTA image build to succeed.
Bug: 173653839
Bug: 182319837
Test: add vendor_dlkm, odm, odm_dlkm to dynamic partitions + make dist
Change-Id: I899810c7f46e40730280d89b94047779705b6e2f
Fix two typos in Makefile.
It turns out that BOARD_ODM_VENDOR_DLKMIMAGE is not correct.
Need to replace it with BOARD_PREBUILT_ODM_DLKMIMAGE.
Test: use grep to check usage
Change-Id: If73b15d7abb7504aa313d616f6cef2d80d76705d
Existing BoardConfig.mk variable:
BOARD_BUILD_VENDOR_RAMDISK_IMAGE := true
generates:
out/target/product/<name>/vendor_ramdisk.img
Extend the above to additionally generate:
out/target/product/<name>/vendor_ramdisk-debug.img
as the two ramdisks should be built together.
Test: make
Change-Id: Ief572e30c9225d0f5569e9ff89096c69accafc7f
