Needed to enable a prebuilt bootloader to make it to the dist and img
directories.
Added a flag to ensure only devices that request will have the update
package populated with a bootloader
Bug: 164917252
Test: local build and Treehugger build
Change-Id: Id67b7bddda14b51a523f794976591c6de04d71ca
* changes:
add support to non-A/B for multiple kernels, boot images
add BOARD_GKI_NONAB_COMPAT for non-A/B compatability with GKI
fix recoveryimage-nodeps
Merge all the proguard_usage.zip files produced by the R8 rules and
dist the result.
Bug: 151857441
Test: m TARGET_BUILD_APPS=DocumentsUI dist
Change-Id: I7e6d73241478016093a203dc7bd86407ab86a4ac
This hasn't worked for a couple years, and continues to bitrot. Just
remove it.
Test: treehugger
Change-Id: Iea6caf3c08252a560155e095135c5ddaad712991
Merged-In: Iea6caf3c08252a560155e095135c5ddaad712991
Apparently needed for cts tests due to apks putting intermediate files under
TARGET_OUT even when going to HOST_OUT.
Test: m with and without change verified no differences in notice files
Change-Id: Iea50b6bd9af9452a2600c97e2f7cb89218b9be7f
* changes:
Create $OUT/{vendor,odm}/lib before symlink modules
Add odm_dlkm/etc/build.prop
Install ODM dlkm to appropriate place and symlink
Add notice files for odm_dlkm
Add odm_dlkm partition.
- Adds makefile and which files are installed to the SOONG_CONV CSV file
- Updates soong_to_convert.py to be able to parse that
- Adds new script that is more detailed.
- Outputs that file as part of the droidcore build to
$(OUT_DIR)/target/product/$(TARGET_DEVICE)/mk2bp_remaining.html
Test: m out/target/product/$(get_build_var TARGET_DEVICE)/mk2bp_remaining.html
Change-Id: I7c380b6070754f4329bf3965595751e4dac794a0
We put reproducible timestamps in zip files so that the artifacts
are consistent, but that leads to old timestamps in the output
directory if they are unzipped as part of the build. Use
unzip -DD when unzipping to update the timestamps.
Bug: 161015009
Test: touch -d 2020-01-01 ref; find $OUT/system -not -newer ref
Change-Id: I6f08ba8695d90a8225cfc04e679755e6296deed0
This is used when Soong and Make don't know the full output file list,
and so use a tool to generate a per-module apkcerts.txt file instead.
Fixes: 160119159
Test: m apkcerts-list
Merged-In: I48183bc8cbf9dcc521f791812734205ed3f28f4c
Change-Id: I48183bc8cbf9dcc521f791812734205ed3f28f4c
This is used when Soong and Make don't know the full output file list,
and so use a tool to generate a per-module apkcerts.txt file instead.
Fixes: 160119159
Test: m apkcerts-list
Change-Id: I48183bc8cbf9dcc521f791812734205ed3f28f4c
If multiple kernels are defined for a build, use the first one when
generating the kernel config file.
Bug: 159975506
Change-Id: Ia136264eb0d0b544bf0685bc22e600de187a9a9b
* As a side product .strip() calls in releasetools are redunant,
but since these scripts are also used out of tree we can't
remove them to guarantee compatibility
Test: m dist
Change-Id: I5c513a4654e293c3d4eab98c8759ea094015fab1
If the BoardConfig defined BOARD_VENDOR_KERNEL_MODULES_LOAD and
BOARD_VENDOR_CHARGER_KERNEL_MODULES_LOAD, generate both a
modules.load and modules.load.charger respectively on
/vendor/lib/modules.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 159424228
Bug: 151950334
Test: build, confirm, change to charger mode, confirm set of modules loads
Change-Id: I55677ed74d80ff3909fe8cbe26e6766f9b5283d5
A call to lz4 was added in http://go/aog/1329115. But the binary
isn't added to otatools, leading to a signing failure.
Bug: 159656873
Test: build otatools
Change-Id: I9cab00f36ce3c39cc174b4c9feffdf360f0364ef
(cherry picked from commit 3031c29905)
A call to lz4 was added in http://go/aog/1329115. But the binary
isn't added to otatools, leading to a signing failure.
Bug: 159656873
Test: build otatools
Change-Id: I9cab00f36ce3c39cc174b4c9feffdf360f0364ef
The gcc tools are deprecated; replace with the llvm equivalent.
Bug: 158484106
Merged-In: I9c3717bde281667eec82cc21dc63dc7fd5592a46
Change-Id: I9c3717bde281667eec82cc21dc63dc7fd5592a46
The extension for the generated vendor ramdisk should be updated based
on the compression scheme used.
Bug: 158433703
Change-Id: I25fff0b8a7879f6aa6d6fe2fce9f5a53f90eb636
system_other is relevant partition to system over vendor.
so move notice files from system_other from vendor to system
Bug: 159189171
Test: m nothing && check ninja dependency
Change-Id: Ib69bd3faae03f174671d5db8366a59b7d28a9d9d
Multiple boot images can be generated based on BOARD_KERNEL_BINARIES
but vbmeta would capture the image descriptor of only the first boot
image specified in BUILT_BOOTIMAGE_TARGET.
Bug : 158213759
Test: Compile multiple boot images and check if vbmeta.img
includes image descriptor of only the first boot image
specified in BUILT_BOOTIMAGE_TARGET
Change-Id: Ib70f65d98546a436da82656bc5c911d437618bb5
Merged-In: Ib70f65d98546a436da82656bc5c911d437618bb5
Instead of copying the logic (which led to divergences), use the
same list of dependencies for both users of build-recoveryimage-target
Bug: 158774198
Test: treehugger
Test: build-coral.ninja is the same before/after
Change-Id: I8f8c006432f3b8120df1f39c98009155fdff32ad
Merged-In: I8f8c006432f3b8120df1f39c98009155fdff32ad
(cherry picked from commit d120ac68fa)
Instead of copying the logic (which led to divergences), use the
same list of dependencies for both users of build-recoveryimage-target
Change-Id: I8f8c006432f3b8120df1f39c98009155fdff32ad
Test: treehugger
The core android build platform has changed to add support for LZ4
compression for ramdisks, but the release tools were not. Fix this.
Bug: 156129966
Merged-In: I39680b91930d2d3cbd0cd565beb78e1ee699397e
Change-Id: I39680b91930d2d3cbd0cd565beb78e1ee699397e
Setting this flag enables unbundled building, i.e. without support for
building the system image and other platform targets. This
functionality was previously enabled by TARGET_BUILD_APPS, and setting
that still implies TARGET_BUILD_UNBUNDLED.
This helps unbundled builds that aren't apps, e.g. ART runtest builds.
Specifically, with the topic of the child CL
https://r.android.com/1324517 TARGET_BUILD_UNBUNDLED does not imply
disabling dexpreopting, unlike TARGET_BUILD_APPS.
TODO: There may still be app-specific conditions that are incorrectly
controlled by TARGET_BUILD_UNBUNDLED, in particular on the Soong side
through config.UnbundledBuild().
Test: Flash & boot
Test: TH, in particular builds green on ub-launcher3-master
Bug: 157549171
Change-Id: Ic09fc879117ee06cab5444edfc280ed2b52d2870
The core android build platform has changed to add support for LZ4
compression for ramdisks, but the release tools were not. Fix this.
Bug: 156129966
Change-Id: I39680b91930d2d3cbd0cd565beb78e1ee699397e
Multiple boot images can be generated based on BOARD_KERNEL_BINARIES
but vbmeta would capture the image descriptor of only the first boot
image specified in BUILT_BOOTIMAGE_TARGET.
Bug : 158213759
Test: Compile multiple boot images and check if vbmeta.img
includes image descriptor of only the first boot image
specified in BUILT_BOOTIMAGE_TARGET
Change-Id: Ib70f65d98546a436da82656bc5c911d437618bb5
Like other <partition>/build.prop files, the build rule for
system/build.prop is also created using the build-properties macro.
system/build.prop has a few number of auto-generate properties that the
macro doesn't create. Those properties are emitted to intermediate files
using manually crafted rules, the paths to the files are fed to the
macro, where their contents are copied to system/build.prop.
This change also refactors the code fragment that defines BUILD_*
variables that identifes the given build.
Bug: 117892318
Test: m
Change-Id: Ic218283b40fedeaddacb3fda93167edbec86094c
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
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
Modify add_img_to_target_files.py to use the BUILDING_*_IMAGE flags when
deciding whether to create and add a given image to a target files
archive.
To do this, the BUILDING_*_IMAGE flags are now dumped to misc_info.txt.
The origin of this change was to use the BUILDING_USERDATA_IMAGE and
BUILDING_CACHE_IMAGE flags in add_img_to_target_files.py so that we
could reliably turn off the generation of the userdata and cache images.
The other image flags were added for symmetry.
Bug: 130307439
Test: m -j out/target/product/bonito/misc_info.txt
Test: m -j droid dist
Change-Id: I32d5a8d6c9ebb5f329d856030084d698ee8d271d
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
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
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
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
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
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
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
The module-load-list-copy-paths fn takes five parameters.
Merged-In: I7d1736da1599e265793173a741053d8a09f1622f
Change-Id: I9286c9e4ca81caf5392bc804dead718bd028b193
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: I7d1736da1599e265793173a741053d8a09f1622f
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
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>
Merged-In: I248d4e2097992f00975b344b5da41aa5d8016812
Change-Id: I248d4e2097992f00975b344b5da41aa5d8016812
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
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
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
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
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
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
Contents that were in /vendor/default.prop are now in /vendor/build.prop
The content is placed at the top of build.prop to keep the existing
order between default.prop and builld.prop.
Bug: 117892318
Test: TH passes
Test: inspect /vendor/build.prop and check if it has contents from
the old /vendor/default.prop file
Change-Id: Ifa1f1dca3b4f4a5fa87d26b8ee058ee706dc54bb
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)
PRODUCT_PACKAGES contains "simple module name" and "bitness suffix".
Call `resolve-bitness-for-modules` to resolve module bitness before
using PRODUCT_PACKAGES.
Bug: 155869107
Test: TH presubmit build_test
Test: check the value of event_log_tags_src
Change-Id: I95fcd833990b3401892c2f7859c83acd90f9e920
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.
Bug: 156036850
Bug: 155049180
Change-Id: I73b70a4d52c2662c3015899632bb8a2b424108d5
'os_version' and 'os_patch_level' are not defined in vendor boot image header,
so remove INTERNAL_MKBOOTIMG_VERSION_ARGS to avoid confusion
Test: lunch aosp_cf_x86_64_phone-userdebug; m vendorbootimage
Change-Id: I19c82846c9669bbd5475605e8b2457744040390d
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
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
_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
Exempt-From-Owner-Approval: cherry-pick from AOSP
Merged-In: I56bc55e2231eb946617a9d6f97d55c9b61f3bff7
(cherry picked from commit f58fd52b14)
Change-Id: I56bc55e2231eb946617a9d6f97d55c9b61f3bff7
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
RECOVERY_FROM_BOOT_PATCH has been moved to vendor as per b/68319577. Hence,
the reserved size should be moved from system to vendor as well.
Bug: 68319577
Bug: 153581609
Test: m target-files-package for non-A/B devices
Change-Id: I2fd3fea10ec6dd06f19c5be753d63ddff1ec01f7
(cherry picked from commit 9a3cad95a9)
Merged-In: I2fd3fea10ec6dd06f19c5be753d63ddff1ec01f7
RECOVERY_FROM_BOOT_PATCH has been moved to vendor as per b/68319577. Hence,
the reserved size should be moved from system to vendor as well.
Bug: 68319577
Bug: 153581609
Test: m target-files-package for non-A/B devices
Change-Id: I2fd3fea10ec6dd06f19c5be753d63ddff1ec01f7
There were still two places where we weren't using it. There may be
more, but these are the ones that come up with aosp_cf_x86_phone.
Test: m out/target/product/vsoc_x86/root/default.prop
Test: m out/target/product/vsoc_x86/obj/NOTICE_VENDOR.txt
Change-Id: I17671ca2ed60332aed2bf76aa00e42a92661b58a
* changes:
generate multiple boot.img files in aosp_arm64
create emulator_arm64 device for sdk_phone_arm64 to use
support multiple boot.img files in release tools
multi boot.img support cleanups
Generate boot.img variants with different schemes for kernel compression
(gzip, lz4, none).
The boot image is removed from vbmeta for aosp_arm64 since it is
not possible currently to store the hashes of multiple variants of a
particular image. The GKI will be verified via VTS anyway.
Also remove some emulator-specific stuff from aosp_arm64.
Bug: 151094943
Change-Id: I465ea6c98d52e839284d51b246203f6b8dfb5566
Merged-In: I465ea6c98d52e839284d51b246203f6b8dfb5566
Support for generating multiple boot.img files is required in the
release tools to enable GKI distribution/signing.
Bug: 151094943
Change-Id: I536a286d3123f35918106a52c49b1148d746370f
Merged-In: I536a286d3123f35918106a52c49b1148d746370f
The kernel should not be specified in INTERNAL_RECOVERYIMAGE_ARGS, since
it is already given to mkbootimg directly.
The MKBOOTIMG_KERNEL_ARG macro is unused.
Bug: 151094943
Change-Id: Ie16a7bf7d77c0436d933abbb02c6dcb9202d5fe7
Merged-In: Ie16a7bf7d77c0436d933abbb02c6dcb9202d5fe7
This tool must match the one used to compile the source code for
compatibility.
Bug: 143977934
Test: m CLANG_COVERAGE=true dist
Merged-In: I71e0e7afb05dedd5f6a09d5e4099387c6262387f
Change-Id: I71e0e7afb05dedd5f6a09d5e4099387c6262387f
(cherry picked from commit b02f7dbaa4)
Generate boot.img variants with different schemes for kernel compression
(gzip, lz4, none).
The boot image is removed from vbmeta for aosp_arm64 since it is
not possible currently to store the hashes of multiple variants of a
particular image. The GKI will be verified via VTS anyway.
Also remove some emulator-specific stuff from aosp_arm64.
Bug: 151094943
Change-Id: I465ea6c98d52e839284d51b246203f6b8dfb5566
Support for generating multiple boot.img files is required in the
release tools to enable GKI distribution/signing.
Bug: 151094943
Change-Id: I536a286d3123f35918106a52c49b1148d746370f
Ram Muthiah