When kernel modules are being put directly into lib/modules/ (as opposed
to lib/modules/<subdir>/), the empty part of the destination path causes
a target containing a redundant /. If the target is also added elsewhere
in the build without the redundant /, then rule merging will miss it,
and a build error will occur.
Bug: 158158635
Change-Id: I797addce760f4886166efa283302a53783581625
Merged-In: I797addce760f4886166efa283302a53783581625
New jar that needs to be packaged for suites.
Test: make cts
Bug: 149758913
Bug: 156482663
Merged-In: If29508f3dd30939be603ed03f2536c960ca40d92
Change-Id: If50a1e76ffdb4651bf004b26eb111e113569c6c4
allow to also skip the stripping of the modules present in vendor
ramdisk when the BOARD configuration is set to skip the strip step.
there is also a shortcoming of this functionality: it currently assumes
the modules to strip are all created equal against the same arch in
particular, however this does not work for kernel modules which are
for mixed mode platforms, as example {kernel,android} == {aarch64,armv7}
because it will select the "android" mode strip which is unaware of the
kernel mode architecture.
Bug: 156395749
Bug: 155193290
Change-Id: I35ef51845224e94e3e253acdeb6bb14b990a401b
Signed-off-by: Pierre Couillaud <pierre@broadcom.com>
Refactor the build support for kernel modules. This refactoring is
leveraged to add support for directories of kernel modules in each
partition. To add a directory of kernel modules, define
BOARD_KERNEL_MODULE_DIRS to include the directory name, for example:
BOARD_KERNEL_MODULE_DIRS := 5.4
The build will then check all the usual kernel module related macros
with an extension of _5.4, for example you can define
BOARD_VENDOR_KERNEL_MODULES_5.4 := <modules to copy>
BOARD_VENDOR_KERNEL_MODULES_ARCHIVE_5.4 = <path to archive file>
BOARD_VENDOR_KERNEL_MODULES_LOAD_5.4 := <modules for load list>
Bug: 157645635
Change-Id: I1687d0ec85c1dcf21350350623b4689aba3f6717
Merged-In: I1687d0ec85c1dcf21350350623b4689aba3f6717
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)
Force generate a non-A/B update package when requested.
Bug: 154344887
Test: ota_from_target_files.py --force_non_ab ...
Test: apply it as well
Change-Id: I5e81eb161722e07ef50081b6a16685cbc9963ae2
This reverts commit 6e1fa4452b.
Reason for revert: relanding a reverted changed
Bug: 153073816
Test: m
Exempt-From-Owner-Approval: cherry-pick from AOSP
Merged-In: I3735866776cf6eb0320c9fb8c6be8ac0c48baa1c
(cherry picked from commit 403c255b6f)
Change-Id: I3735866776cf6eb0320c9fb8c6be8ac0c48baa1c
With I1889653812a980f6a2e3b6b25e7647f7c5919606, libvixl is not available
to the platform as it is included in the ART APEX. To use the APEX
variant of the library, we use the <name>:<apex_name> notation.
Bug: 150999716
Test: m
Change-Id: I2206f1c28fc0019c0fd726059aa732145f2998ed
This change fixes a regression that was caused by I56bc55e2231eb946617a9d6f97d55c9b61f3bff7
that file names for Make modules are ".apk" in apkcerts.txt.
This was because PACKAGES.$(LOCAL_MODULE).STEM was only set for the
modules from Soong. It is now set for Make modules too.
Bug: 155440232
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m apkcerts-list
and check the generated apkcerts txt file to see that it doesn't have an
entry where file name is ".apk"
Change-Id: I6f14bbb5678255bef2c1f2397f59ede6c2b5df18
BUG: 149826779
Test: Build x86, x86_64, armv7 and arm64
make sure x86/64 boot to home screen;
armv7/arm64 can pass disk mounting stage
Change-Id: I258b69bd0cdc4fb0a99b1a04567051e8d32c389a
Merged-In: I258b69bd0cdc4fb0a99b1a04567051e8d32c389a
_apkcerts_write_line has assumed that the stem name of a package is the
same as the module of it. That assumption however breaks for
APK-in-APEX, in which case the stem name is Foo while the module name is
Foo.com.android.bar (where com.android.bar is the name of the APEX where
the APK is in).
Fixing the issue by recording the stem name and use it.
Bug: 155440232
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m apkcerts-list
and check the generat4ed apkcerts txt file to see that it has
Tethering.apk instead of Tethering.com.android.tethering.apex
Change-Id: I56bc55e2231eb946617a9d6f97d55c9b61f3bff7
