* Streamline required module bitness resolution
If a module is for cross host OS, the required modules are also for that
OS.
Otherwise if the requirer module is native and the required module is
shared library or native test, then the required module resolves to the
same bitness.
Otherwise the required module resolves to both variants, if they exist.
* Factor out the common logic and merge
<target|host|host-cross>-select-bitness-of-required-modules
This lays the road for follow-up changes to add bitness suffix support.
This slightly reduces readibility. To make up for the loss, the
bitness-resolving logic is easier to maintain since we don't have
multiple copies of *-select-bitness-of-required-modules.
Bug: 155869107
Test: check the diff of product_target_FILES and product_host_FILES
Test: check the diff of ALL_MODULES.*.REQUIRED_FROM_(TARGET|HOST)
Change-Id: Ib2f4b548535e983d621dad71cb920101111140f2
It may be needed in class loader context if the target API version
is less than 30.
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: Ifa5ab18d1dc322184100207ad6eee4bdcf74deb0
The module-load-list-copy-paths fn takes five parameters.
Merged-In: I7d1736da1599e265793173a741053d8a09f1622f
Change-Id: I9286c9e4ca81caf5392bc804dead718bd028b193
* changes:
Drop the dependency from vendor/build.prop to system/build.prop
Remove ro.bootimage.* sysprops
ro.build.expect.* sysprops are created in a separate rule
Make use of ADDITIONAL_ODM_PROPERTIES
Refactor post_process_props.py
remove code for default.prop
Make more use of ADDITIONAL_VENDOR_PROPERTIES
ADDITIONAL_*_PROPERTIES are props determined by the build system
First, make it safer for incremental builds. We used to just be
depending on the bootable/recovery/tools/recovery_l10n/res dir as a
dependency, but that would only trigger a rebuild if a direct child
file/directory was added or removed (so essentially, when a translation
was addded or removed). If a translation was updated, it wouldn't
re-trigger recovery_text_res.
So instead of depending on the directory, depend on the results from
running `find` to list all of the contents in that directory.
Next, move it out of PACKAGING. `m installclean`, which runs in between
incremental builds on our build servers, deletes the obj/PACKAGING
directory. So when recovery_text_res used that directory, we were having
to rebuild it on every incremental build, which isn't optimal when it
takes nearly 90s to build.
So with:
$ lunch aosp_coral-eng
$ m bootimage
$ m installclean
$ m bootimage
The second `m bootimage` went from executing 666 actions in 93s to
executing 658 actions in 6s.
Finally, remove the last uses of $(call include-path-for,recovery),
since they were all in this file (and they weren't using it for include
paths...). We'd like to remove all of these and switch them to header
libraries or other use cases, but in this case, it's just shorter to use
the real path.
Test: treehugger
Test: m bootimage;
touch bootable/recovery/tools/recovery_l10n/res/values/strings.xml
m bootimage
Test: m bootimage; m installclean; m bootimage
Change-Id: I005592e49443aab45ed039a2f0c63f7a69035565
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>
Change-Id: Iac9538e6ee6ec51e6b487de2101f53bb5d9c54c8
The former doesn't use anything from the latter. The dependency is not
needed.
Bug: 117892318
Test: m
Change-Id: I61aeea9feb1ac4467af4f185f3d6930b03145afd
ro.bootimage.build.date.* are not used anywhere.
ro.bootimage.build.fingerprint was used in the recovery mode, which has
now been switched to ro.build.fingerprint.
Bug: 117892318
Test: m
Change-Id: I3776c4154f86ddb908b24c6899037c6a7df037df
This change is required to unify the build rules for */build.prop files;
The rules shouldn't have partition-specific actions.
Bug: 117892318
Test: m
Manually inspect ro.build.expect.[bootloader|baseband] props in
vendor/build.prop
Change-Id: I3b29b2728f779a9d7e1d71a5aa69b02ea940b3c6
Properties that were defined in the build rule for odm/build.prop are
now defined via ADDITIONAL_ODM_PROPERTIES.
Bug: 117892318
Test: m
Change-Id: I6220e217d0724b6e27127786e7a908e1e662d1a0
The script is refactored to not parse lines everytime a prop is looked
up or updated.
Also it is now built using python_binary_host.
Bug: 117892318
Test: m
Change-Id: I1677ca5aa919c54b7b0740fdc52e1399009f9a12
Properties that were defined in the build rule for vendor/build.prop are
now defined via ADDITIONAL_VENDOR_PROPERTIES.
Bug: 117892318
Test: m
Change-Id: Ib3dc9d001a8dcd0aa38f1acae384a96b67b5af8a
This change defines ADDITIONAL_<partition>_PROPERTIES to store properties
determined by the build system itself.
ADDITIONAL_SYSTEM_PROPERTIES was originally ADDITIONAL_BUILD_PROPERTIES.
ADDITIONAL_VENDOR_PROPERTIES was originally FINAL_VENDOR_DEFAULT_PROPERTIES.
ADDITIONAL_PRODUCT_PROPERTIES has been there and thus not changed.
ADDITIONAL_ODM_PROPERTIES is newly defined, although it is empty now.
In addition, ADDITIONAL_VENDOR_PROPERTIES are now defined in
core/main.mk along with other ADDITIONAL_*_PROPERTIES.
Bug: 117892318
Test: m
Change-Id: Ic41bba2e5695355436ac8df353866cfc044e1e0b
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>
Merged-In: I248d4e2097992f00975b344b5da41aa5d8016812
Change-Id: I248d4e2097992f00975b344b5da41aa5d8016812
When we do 64-32 migration, we want compare mode to be present only for
non-c++ actions as it would impact performance on 32-core machines
otherwise.
Bug: b/157414300
Test: Ran a build with "RBE_CXX_LINKS="true" RBE_CXX_LINKS_EXEC_STRATEGY="remote" RBE_CXX_COMPARE="false" RBE_compare="true" use_rbe mmma bionic"
and observed that local-executions happened only for link actions and
not for C++ actions.
Change-Id: Ia972c74d804085196a7b6ec755af63042c6b3909
If used, the results would be inaccurate in any case.
Deleted atest references: http://aosp/1315404http://aosp/1315405
Test: treehugger
Test: atest -c --rebuild-module-info com.google.android.gts.updateengine.UpdateEngineHostTest
Change-Id: I6efbf1f5ff3a533b26d6bbedc14a6fcc1b200391
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: Ia88c8efecb18db9c27baa466e492bfd898b581d3
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.
Change-Id: Ib2925aec6ea7a2a01a554c808d6697d8c85f9fc0
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
Yo Chiang