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
Bootconfig does not allow the keys to have values and subkeys at the
same time.
"androidboot.hardware" and "androidboot.hardware.*" subkeys have existed as
kernel cmdline parameters. We want to throw an error at build time when
"androidboot.hardware" is use in bootconfig because it may be a common
occurence while migrating to bootconfig.
"hardware" should be used instead, without the "androidboot" prefix.
Test: build with and without "androidboot.hardware=test" in
BOARD_BOOTCONFIG
Bug: 173815685
Change-Id: Ic62a86cb23c9d79dbdbacd18eed3449210566ce7
Remove unnecessary @ and $(hide) from fileslist target commands.
Keep @echo to print that line with a progress bar [ x% x/y ].
Test: make
Change-Id: I65c0c3c9c045cc7ca2c2801ee6b3b0c996be59a9
Allow BoardConfig.mk to set:
BOARD_BUILD_VENDOR_RAMDISK_IMAGE := true
to build:
out/target/product/<name>/vendor_ramdisk.img
This is done to support GKI device kernel development.
Kernel developers build vmlinux + DTB + GKI kernel modules locally
and then use kernel build tools to output:
* vmlinux + ramdisk.img => boot.img
* GKI kernel modules + DTB + vendor_ramdisk.img => vendor_boot.img
In other words, kernel developers use ramdisk.img and vendor_ramdisk.img
as prebuilts for building flashable boot.img and vendor_boot.img
directly from the kernel development environment.
Test: make vendorramdisk with BOARD_BUILD_VENDOR_RAMDISK_IMAGE := true
Test: make vendorramdisk with BOARD_BUILD_VENDOR_RAMDISK_IMAGE omitted
Change-Id: Id67839887b6bf608f4a5f13384c551c12ee9fdbd
Commit I66b57de91042bfd56ba54a3659843d8cf7873955 added the support
for different boot partition sizes but didn't consider the case of
building boot-test-harness.img. This CL fixes this by allowing
'boot-test-harness.img' as a boot image variant.
Bug: 181618515
Test: `m bootimage_test_harness` pass
Change-Id: I190d3bf26725ac54999758efbca66a94c5cd5c86
Rename to get consistent ramdisk directory naming in
out/target/product/<name>:
debug_ramdisk
ramdisk
vendor_debug_ramdisk
vendor_ramdisk
Test: build and inspect out/target/product/<name>
Change-Id: I81d8f2cafe5e1b9024196cd74772b78d4a4aec58
target-files.zip may indirectly depend on the rsync'd recovery ramdisk
files when BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT is true.
Bug: 181095653
Test: manual
Change-Id: I673bb48b1fbb7a54455cda411f9444f05ddaa24f
This follows the same steps as OpenSplitPolicy() in
system/core/init/selinux.cpp on the device.
Bug: 178864050
Test: merge_target_files for R+S and S+S devices
Test: test_merge_target_files
Change-Id: Ia41a436bfda8e2cb65706122f0ff3805b99d16e1
Gather all BOARD_BOOTCONFIG parameters.
Create vendor-bootconfig.img with parameters seperated by newlines. Pass
that file to mkbootimg as --vendor_bootconfig to add it to the
vendor_boot.img.
Test: Add BOARD_BOOTCONFIG parameters in cuttlefish .mk file
Check vendor-bootconfig.img for expected output
Verify expected vendor_boot.img format with:
unpack_bootimg --boot_image vendor_boot.img
Test: Update Cuttlefish bootloader to handle the new vendor_boot.img and
check /proc/bootconfig for the expexted parameters.
Bug: 173815685
Change-Id: Iaa9b71b4bc64375777a5353396e83bb2beb25c47
repack_bootimg is useful to add files into a ramdisk, then repack
a boot.img. Note that mkbootimg, unpack_bootimg, lz4, minigzip, etc.,
that repack_bootimg depends are already in otatools.zip.
Bug: 174443192
Test: `m otatools-package`, unzip $OUT/otatools.zip, export $PATH
with ./otatools/bin and checks unpack_bootimg can run
Change-Id: Id4fbf2076b50522b95ab46dfeb1e2b7115d6606d
BOARD_<partition>_KERNEL_MODULES_BLOCKLIST_FILE<kernel_version> checks
the syntax of and installs a prebuilt modules.blocklist file.
Example usage:
```
BOARD_VENDOR_KERNEL_MODULES_BLOCKLIST_FILE := \
$(wildcard <path to prebuilt modules.blocklist>)
```
Then the modules blocklist would be install to
(vendor|vendor_dlkm)/lib/modules/modules.blocklist.
Bug: 175165656
Test: Create a blocklist with incorrect syntax, verify build fails
Test: Verify the new macro indeed installs the blocklist file
Change-Id: Icb75aae1bdb45546792f28f4c4e8d06d9439391a
target_files.zip passes a list of files to soong_zip in a file list
file, which soong_zip interprets as a glob. Adding a file called "["
causes soong_zip to error with "syntax error in pattern". Use an RSP
file instead, which after I1de7829c668538204fc4a2ac793a4f88dbc886c9
does not interpret entries as globs.
Bug: 179297188
Test: m target-files-package
soong_zip: don't glob RSP file entries
File arguments are considered globs, but RSP file entries should be
considered filenames without globbing. Escape RSP file entries so
they don't get treated as globs later.
Bug: 179297188
Test: zip_test.go
Change-Id: I0736f2d1802114217cba03ee32b67479c9d98da8
vendor-ramdisk-debug.cpio.lz4 will be packed into a
vendor_boot-debug.img and usually won't be flashed directly.
Moving it to the intermediate build directory.
Bug: None
Test: make vendorbootimage_debug
Change-Id: I86ea72c7a3484a90286139624408d07ce4bf994c
Test: mm -j && mm -j dist, make sure virtual_ab_compression is set to
true in dynamic_partition_info.txt of target_File.zip
Change-Id: Id0d46bd8ed738b2b69a0c01481b7db0c7127f773
When building vendor_boot v4 with multiple vendor ramdisks, pass the
name of each ramdisk to mkbootimg.
Bug: 177882072
Test: Modify a device BoardConfig and verify the built vendor_boot.img
with unpack_bootimg
Change-Id: I679d277aa88f1e10678d2f74b579e4140536e267
Commit I56dda56bab7def1540f4fb506323e3e605620cd4 adds
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT and includes
$(TARGET_RECOVERY_ROOT_OUT) directory when building vendor
ramdisk if BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT is set.
We should do the same thing when building the vendor debug
ramdisk as well. Otherwise, lacking some recovery files
makes the device unable to boot into fastbootd/recovery mode.
Bug: 177712689
Test: `make vendorbootimage_debug`, then unpack
./obj/PACKAGING/vendor-boot-debug_intermediates/vendor-ramdisk-debug.cpio.lz4
to check it includes recovery resources via:
`lz4 -d -c ../vendor-ramdisk-debug.cpio.lz4 | cpio -idm`
Test: device can boot into fastbootd after flashing vendor_boot-debug.img
Change-Id: I4744c6600866436ed7d5a321e67e20b8f3da8a81
As we add more partitions, INTERNAL_*IMAGE_FILES variables has grown
and the places where the variables are referenced had to be touched
everytime. This change introduces a new variable
INTERNAL_ALLIMAGES_FILES which concatnates INTERNAL_*IMAGE_FILES, and
replaces the uses of the variables with the new one.
Bug: N/A
Test: m
Change-Id: I62a0f725a0f6999421d04a6261370be9124e62d7
Add support for partitioning the vendor_boot kernel modules into
multiple vendor ramdisk fragments. The partition granularity is kernel
module directory. This mechanism builds upon the existing
BOARD_KERNEL_MODULE_DIRS mechanism. For example, say we have three
kernel module directories:
BOARD_KERNEL_MODULE_DIRS := foo bar baz
We can then define a vendor ramdisk fragment:
BOARD_MKBOOTIMG_ARGS += --header_version 4
BOARD_VENDOR_RAMDISK_FRAGMENTS := dlkm_foobar
And let said ramdisk to contain the DLKM directories "foo" and "bar":
BOARD_VENDOR_RAMDISK_FRAGMENT.dlkm_foobar.KERNEL_MODULE_DIRS := foo bar
BOARD_VENDOR_RAMDISK_FRAGMENT.dlkm_foobar.MKBOOTIMG_ARGS := <mkbootimg args>
The built vendor_boot image would contain two ramdisks.
The first one being the "default" ramdisk, which contains DLKM directory
"baz" and the rest of the files that get's installed to
$(TARGET_VENDOR_RAMDISK_OUT).
The second one is the "dlkm_foobar" ramdisk, which contains the two DLKM
directories.
Design doc: go/vendor-boot-v4
Bug: 162864255
Test: Modify BoardConfig.mk to have a product build v4 vendor_boot
Test: Use unpack_bootimg to verify the vendor_boot image
Test: Teach a bootloader how to handle v4 boot image, flash boot &
vendor_boot and boot device
Change-Id: Ibb1bbd7ebe36430c55ec6c4818c1d3888a319089
Yi-Yo Chiang