Use ALL_MODULES.*.PATH to check module existence.
Use get-modules-for-2nd-arch to check the existence of second arch
variant.
Fix some typos *existant -> existent
Bug: 155869107
Test: lunch mainline_system_arm64; m
Test: lunch generic; m
Change-Id: Ic10fb34a11da0bfbfc528da7496fd929b1d77113
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
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
(cherry picked from commit 7169f754cc)
Merged-In: I5e81eb161722e07ef50081b6a16685cbc9963ae2
As we merge default.prop into build.prop, we don't need to distinguish
ADDITIONAL_DEFAULT_PROPERTIES and ADDITIONAL_BUILD_PROPERTIES. Deprecate
the former in favor of the latter.
Bug: 117892318
Test: m
Change-Id: I80341c2e05d70821396202dc9e94104625ebf024
There is no change in functionality. This change just changes the
location of the code.
Bug: 117892318
Test: m
Change-Id: I0935f611069aeae867edefe8ca61bddb2aae4c78
This is a partial cherry-pick of Iaeefb35137de01c6ea57115d8830dd9bc30eccba
to prevent merge conflicts that are expected with the upcoming major
refactoring around sysprops.
The addition of the variable here doesn't cause any side effect because
it is simply ignored by the buildinfo.sh tool.
Bug: 117892318
Test: m
Change-Id: Ia805cb47ae07c40e91ede16bb6e5c4291de619b4
Merged-In: Iaeefb35137de01c6ea57115d8830dd9bc30eccba
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
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
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
It was kept for non-Treble devices, but now /system/build.prop is used
instead by having both system-configured sysprops and vendor-configured
sysprops. To summarize:
* For Treble compliant devices
- /system/build.prop has
ADDITIONAL_DEFAULT_PROPERTIES
PRODUCT_SYSTEM_DEFAULT_PROPERTIES
props generated from buildinfo_common.sh
props generated from buildinfo.sh
props read from TARGET_SYSTEM_PROP file
ADDITIONAL_BUILD_PROPERTIES
- /vendor/build.prop has
PRODUCT_DEFAULT_PROPERTY_OVERRIDES
props generated from buildinfo_common.sh
props read from TARGET_VENDOR_PROP
PRODUCT_PROPERTY_OVERRIDES
* For non-Treble devices,
PRODUCT_DEFAULT_PROPERTY_OVERRIDES moves from /vendor/build.prop to
/system/build.prop (just after PRODUCT_SYSTEM_DEFAULT_PROPERTIES).
Other props in /vendor/build.prop remain there but they are not used
because it's a symlink for /system/vendor/build.prop and init does not
follow symlink. Especially, PRODUCT_PROPERTY_OVERRIDES is ignored.
Someone might think this as a bug, which actually is, but this change
doesn't attempt to fix that, because 1) that's out of scope of this
change, and 2) we will anyway merge PRODUCT_PROPERTY_OVERRIDES and
PRODUCT_DEFAULT_PROPERTY_OVERRIDES into one.
Bug: 117892318
Test: TH passes
Change-Id: I867f3615ef8c06650ab2ee96642bac4f6d8ca820
Contents that were in /system/etc/prop.default are now in
/system/build.prop.
The content is placed at the top of build.prop to keep the existing
order between the two files.
Caveat: /prop.default still remains for non-Treble devices.
Bug: 117892318
Test: TH passes
Test: inspect /system/build.prop and check if it has contents from
the old /system/etc/prop.default file
Change-Id: Ibc74edb88904f953a1e5e6ceef44c461f381c9cf
