Moving this makes each of the partition's kernel module Makefile
generation more similar, enabling a forthcoming cleanup/refactoring.
If recovery-is-boot and there are kernel modules defined in
BOARD_GENERIC_RAMDISK_KERNEL_MODULES, those kernel modules will
now be included in the default assignment to
BOARD_RECOVERY_KERNEL_MODULES_LOAD. If this is not desired then
BOARD_RECOVERY_KERNEL_MODULES_LOAD may simply be set to
BOARD_RECOVERY_KERNEL_MODULES (or a custom list of recovery kernel
modules to load).
Bug: 157645635
Change-Id: Ia1392b7d20d07cee75420edd95dcee1dc825516e
Merged-In: Ia1392b7d20d07cee75420edd95dcee1dc825516e
Currently the two special-case calls to create just a module load list
(as opposed to copying a set of modules and creating a module load list)
are inside checks that the related board macro for the module set is not
empty.
While it would be incorrect to create a non-empty module load list with
an empty set of modules, this error would quickly surface at runtime.
More importantly, moving these out will permit refactoring this code to
clean it up.
Bug: 157645635
Change-Id: I199788d49072d4c59737b3ef2c75546852cf3e36
Merged-In: I199788d49072d4c59737b3ef2c75546852cf3e36
This check is meant to initialize BOARD_ODM_KERNEL_MODULES_LOAD to
BOARD_ODM_KERNEL_MODULES if BOARD_ODM_KERNEL_MODULES_LOAD is empty.
Bug: 157645635
Change-Id: I9c8ac0e64bb002e926d15b446a63801d7cfa9911
Merged-In: I9c8ac0e64bb002e926d15b446a63801d7cfa9911
Ramdisks are currently compressed using gzip, which is generally
smaller, but slower to decompress than lz4. Provide an option for an
lz4 scheme to reduce the time taken to unpack initramfs during boot.
Bug: 156129966
Signed-off-by: J. Avila <elavila@google.com>
Merged-In: Iac9538e6ee6ec51e6b487de2101f53bb5d9c54c8
Change-Id: Iac9538e6ee6ec51e6b487de2101f53bb5d9c54c8
If the BoardConfig defined BOARD_VENDOR_RAMDISK_MODULES_LOAD and
BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD, generate both a
modules.load and modules.load.recovery respectively on the vendor
ramdisk. BOARD_VENDOR_RAMDISK_MODULES must be the set, or super set,
of all the modules represented in both of *_LOAD BOARD variables.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 151950334
Test: build, confirm, fastboot flashall, boot with split.
Merged-In: Ib2925aec6ea7a2a01a554c808d6697d8c85f9fc0
Change-Id: Ib2925aec6ea7a2a01a554c808d6697d8c85f9fc0
The size of the ramdisk has greatly increased, which can be a source of
boot time regressions. Strip the modules of debug symbols for the vendor
ramdisk and vendor partitions; vendor stripping can be skipped via BOARD
config.
Bug: 156395749
Signed-off-by: J. Avila <elavila@google.com>
Change-Id: I248d4e2097992f00975b344b5da41aa5d8016812
GSI do not build product partition, and contains the product
contents under /system/product/. Original logic do not generate
the product build props on this case.
The patch fixes the logic for product build props generation to
align the other partitions.
Bug: 157191627
Test: build aosp_arm64-userdebug
Test: check /system/product/build.prop in out folder
Change-Id: I350bbf8c024f747c86c6c54065d690f6b46f30c6
Merged-In: Ia88c8efecb18db9c27baa466e492bfd898b581d3
The custom images are any images owned by OEMs and SoCs, oem images
mounted on /oem is an example. The oem images can be used to customize
devices for different carriers, like wallpaper, ringtones, and
carrier-specific apks. OEMs can generate multiple oem images, like
oem.img, oem-carrier1.img and oem-carrier2.img and flash different oem
images for different carriers. The oem images are only one case, OEMs
and SoCs can add more custom images and mount them to custom partitions.
This change enables custom images to be vbmeta.img chained partitions.
The following configuration in BoardConfig.mk is an exmaple. It has two
custom partitions: oem and test. They will be signed by different keys.
And they will be chained by vbmeta.img. The custom images here are
prebuilts, which can be built by `make custom_images` separately.
BOARD_AVB_<CUSTOM_PARTITION>_IMAGE_LIST should include all custom images
to apply AVB signing. And to every custom partition, one image whose
name is partition name must be added in its
BOARD_AVB_<CUSTOM_PARTITION>_IMAGE_LIST.
BOARD_CUSTOMIMAGES_PARTITION_LIST := oem test
BOARD_AVB_OEM_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_OEM_ALGORITHM := SHA256_RSA4096
BOARD_AVB_OEM_ADD_HASHTREE_FOOTER_ARGS :=
BOARD_AVB_OEM_ROLLBACK_INDEX_LOCATION := 1
BOARD_AVB_OEM_PARTITION_SIZE := 5242880
BOARD_AVB_OEM_IMAGE_LIST := \
device/xxxx/yyyy/oem/oem.img \
device/xxxx/yyyy/oem/oem1.img
BOARD_AVB_TEST_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_TEST_ALGORITHM := SHA256_RSA2048
BOARD_AVB_TEST_ADD_HASHTREE_FOOTER_ARGS :=
BOARD_AVB_TEST_ROLLBACK_INDEX_LOCATION := 2
BOARD_AVB_TEST_PARTITION_SIZE := 10485760
BOARD_AVB_TEST_IMAGE_LIST := \
device/xxxx/yyyy/test/test.img \
device/xxxx/yyyy/test/test1.img
To resign the custom images in the target zip file, the
avb_extra_custom_image_key, avb_extra_custom_image_algorithms and
avb_extra_custom_image_extra_args options are added to the
sign_target_files_apks tool too. The following test cases list some
examples about how to use them.
BUG: 154171021
Test: 1) "atest --host releasetools_test releasetools_py3_test -c"
2) Build images by 'make dist', sign and validate target files.
a) Test on dist w/ chained vbmeta_system and ome custom images
sign_target_files_apks -d certs \
--avb_extra_custom_image_key oem=oem_rsa4096.pem \
--avb_extra_custom_image_algorithm oem=SHA256_RSA4096 \
xxx-target_xxx.zip signed.zip
validate_target_files.py signed.zip
Flash image and boot up.
Verify the oem images and vbmeta images in OUT and target zips by
avbtool.
b) Test on dist w/ chained vbmeta_system and oem and test custom images
sign_target_files_apks -d certs \
--avb_extra_custom_image_key oem=oem_rsa4096.pem \
--avb_extra_custom_image_algorithm oem=SHA256_RSA4096 \
--avb_extra_custom_image_extra_args oem=--do_not_generate_fec \
--avb_extra_custom_image_key test=test_rsa4096.pem \
--avb_extra_custom_image_algorithm test=SHA256_RSA4096 \
xxx-target_xxx.zip signed.zip
validate_target_files.py signed.zip
Verify the oem, test images and vbmeta images in OUT and target zips
by avbtool.
c) Test on dist w/o chained partition.
sign_target_files_apks -d certs xxx-target_xxx.zip signed.zip
validate_target_files.py signed.zip
Flash image and boot up.
Verify the vbmeta images in OUT and target zips by avbtool.
Change-Id: Ifccfee5e8909697eef6ccda0cc352fa16a9f6db6
Merged-In: Ifccfee5e8909697eef6ccda0cc352fa16a9f6db6
The different boot images in aosp_arm64 have different partition size
requirements. Add support for defining a partition size associated with
each boot image variant.
This support is limited to aosp_arm64 currently, which is built with
recovery-as-boot.
A previous version of this change did not update the boot-debug image
AVB logic with the required macro for multiple boot partition size
support. This is now required because the aosp-arm64 boot.img is
configured as a chained AVB partition.
Bug: 156036850
Bug: 155049180
Change-Id: I66b57de91042bfd56ba54a3659843d8cf7873955
Merged-In: I66b57de91042bfd56ba54a3659843d8cf7873955
When `OVERRIDE_TARGET_FLATTEN_APEX` is defined (e.g. set in the
environment), `TARGET_FLATTEN_APEX` is forcibly assigned its value.
This is useful to enable/disable APEX flattening from the command
line (thus ignoring the product's default configuration), for testing
purposes.
Note: Previously it was possible to set `TARGET_FLATTEN_APEX` directly
and have the same effect, but recent changes in the build
configuration now prevent that option.
Test: Check that:
export OVERRIDE_TARGET_FLATTEN_APEX=true \
&& . ./build/envsetup.sh \
&& lunch aosp_walleye-userdebug \
&& export OVERRIDE_TARGET_FLATTEN_APEX=true \
&& build/soong/soong_ui.bash --dumpvar-mode TARGET_FLATTEN_APEX
returns:
true
Bug: 121117762
Merged-In: Ib9ccae38430340de38e4758b4f55df2c65ea60d5
Change-Id: Ib9ccae38430340de38e4758b4f55df2c65ea60d5
(cherry picked from commit b3a503df7f)
placeholder
Bug: 134509111
Test: add "test_mainline_modules: [some.apk]" to TetheringTests,
and build the modules, confirm the parameterized option is added
in the test config.
Change-Id: I0f4f837412075520153d21c9ca12cf5c3f555de7
Merged-In: I0f4f837412075520153d21c9ca12cf5c3f555de7
Link type checking is already done within Soong, and
SOONG_SDK_VARIANT_MODULES is not complete yet while parsing Soong
modules, skip JNI link type checking for Soong apps.
Bug: 156225490
Test: m checkbuild
Change-Id: I2f6824b180ccdd62c26497bdca527540ca22f0d7
Merged-In: I2f6824b180ccdd62c26497bdca527540ca22f0d7
(cherry picked from commit 1c8d81e5d9)
Enables signing for them so we can verify that the boot partition
contains a valid generic boot image during the compliance test.
This change also adds the chained partition descriptor of
boot partition into vbmeta.img, which contains the corresponding
public key used to verify the boot partition.
Bug: 151094943
Test: lunch aosp_arm64-user, `make` and use `avbtool info_image`
to check that GKI images are properly signed.
Test: `make dist` and checks that GKI images in the image zip file
are properly signed.
Change-Id: I2fd69964f9dc62526a813875fa9193913aa4935b
Merged-In: I2fd69964f9dc62526a813875fa9193913aa4935b
(cherry picked from commit 0f95ac7e8c)
Steve Muckle