* Extract BUILD_NUMBER, BUILD_HOSTNAME to file to avoid kati change
* Handle FILE_NAME_TAG_PLACEHOLDER string in dist in build/make/packaging/distdir.mk
Test: check if kati isn't invoked even though BUILD_NUMBER, BUILD_HOSTNAME
is changed
Test: m && m, and check if the second m is no-op
Bug: 278060169
Change-Id: I1b37760242853c1a145bad255d0bb15524234b25
Merged-In: I1b37760242853c1a145bad255d0bb15524234b25
verity.mk is used to set the related variable for VB 1.0 support, but
we already removed VB 1.0. This change removes the unused code. We also
remove and block PRODUCT_VERITY_SIGNING_KEY in this change.
Bug: 241044073
Test: atest under build/make
Change-Id: Ifbcde7da27a931ef3b9d746b1c5a279d88c0ec85
PRODUCT_SUPPORTS_VERITY and PRODUCT_SUPPORTS_VERITY_FEC are going to be
deprecated since we removed VB 1.0 support. This change removes the
related references.
Bug: 241044073
Test: atest under build/make
Change-Id: Icee659ff0606cda1ab44e92372d86a394ddf1466
Custom kernel module targets are not in the build dependency rule
which cause the copy command of $(my_copy_pairs) fail.
Add it back to $(my_image_copy_files) and remove the prefixed
$(my_staging_dir) from dest of kernel module copy pair.
Then the makefile can handle it well.
Bug: 195888474
Change-Id: Id8cb4c4991905e8bc53ddb5e60e87a36fe43e803
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Correct the build-image-kernel-modules arguments then
the board can use BOARD_{CUSTOM_IMAGE}_KERNEL_MODULES
to install kernel modules.
Bug: 195888474
Change-Id: I65124acc470e7f6f701bf3c9f5481bb2d688d555
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
`PATH=$(foreach p,$(INTERNAL_USERIMAGES_BINARY_PATHS),$(p):)$$PATH` will
produce a space separated string due to `foreach`, if
$(INTERNAL_USERIMAGES_BINARY_PATHS) has more than one string. We didn't
hit the issue in the past because $(INTERNAL_USERIMAGES_BINARY_PATHS)
had contained only one path in practice.
Test: TreeHugger
Change-Id: I74ef4356668af63d871a81f6bfd4c9324aa1d956
We sometimes see build failures when building platform.zip happens
at the same time as building vendor.img if the vendor.img rule
runs rm -rf $OUT/vendor/lib/modules at the same time that platform.zip
is zipping $OUT/vendor/. Move the kernel modules into normal
installation rules so that they are in place by the time either
the vendor.img or platform.zip rules run.
This will also cause the kernel modules to show up in
installed-files*.txt.
Test: m vendorimage && ls $OUT/vendor/lib/modules
Change-Id: I178b1d54bfcdb5cf5c29885ace9183ac28fc8826
This CL simplifies the PRODUCTS.$(INTERNAL_PRODUCT).X accesses of
product variables, and removes unnecessary stripping of them.
Replace: '\$\(PRODUCTS\.\$\(INTERNAL_PRODUCT\)\.([^\)]*)\)' with '$(\1)'
Replace: '\$\(strip\s*\$\(PRODUCT_([^\)]*)\)\)' with '$(PRODUCT_\1)'
A few minor manual tweaks.
Bug: 116769560
Test: presubmit
Change-Id: I70c54f1582e3cc780028535960147d99ebc2e0e1
<Two phase commits> Since internal master code has more places that use
BUILD_NUMBER (mostly in vendor/) than AOSP (conflict). We can't
deprecate BUILD_NUMBER directly. Therefore, we try to switch to
BUILD_NUMBER_FROM_FILE as much as possible at first. Then we will do
a one-off deprecation for BUILD_NUMBER in internal master next step.
Test: m -j
Bug: b/70351683
Change-Id: I14ffee7381933c9fde14c4bde8c0c14e45fe98bf
Adding verified boot metadata with a "disable magic". The resulting
metadata at the end of each image (e.g., system.img, vendor.img) will
be the same as triggering an "adb disable-verity" on an USERDEBUG image.
This can help simplify the code on fs_mgr, which won't have to check if
current image is an ENG build or not.
Bug: 63056044
Test: boot sailfish eng/userdebug builds
Change-Id: I95d23ac7b76c04d6d4483c9c4dc1de16bf0d9c3a
Current AVB signing for custom images is enabled by either of the
following build variables:
CUSTOM_IMAGE_AVB_HASH_ENABLE := true
CUSTOM_IMAGE_AVB_HASHTREE_ENABLE := true
A previous change to support chain partition replaced avb_signing_args
with avb_key_path and avb_algorithm. This change updates the
corresponding change for custom_images.
To sign a custom_image as a chain partition, it needs:
CUSTOM_IMAGE_AVB_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
CUSTOM_IMAGE_AVB_ALGORITHM := SHA256_RSA2048
CUSTOM_IMAGE_AVB_ROLLBACK_INDEX := 1
Note that it doesn't support include metadata of custom images into
vbmeta.img. Because custom_images is designed to build multiple files
(e.g., custom1.img, custom2.img, custom3.img, etc) and a device can only
use/mount one of them. The vbmeta.img needs to be generated per each
combination.
Bug:36701014
Test: sign custom image with AVB HASH descriptor (non-chain)
Test: sign custom image with AVB HASH descriptor as chain partition
Test: sign custom image with AVB HASHTREE descriptor (non-chain)
Test: sign custom image with AVB HASHTREE descriptor as chain partition
Change-Id: I492e2ce768e7caec22228b776b2c13a2d37a5b89
Bug: 63691195
Test: `make custom_images` with CUSTOM_IMAGE_SUPPORT_VERITY_FEC := true
Test: boot device with the custom image built above
Change-Id: I198fa1e0697cb00712bbfb6f1a717ec623703ede
This patch reuses the build-image-kernel-modules macro to build the
odm/lib/modules directory according to the BOARD_ODM_KERNEL_MODULES
which contains list of kernel module files.
Bug: 36012197
Test: android master build on pixel
Change-Id: I2c004132a89e7f230690b4d26c98c3d5b2769f11
To support extra files in package-modules.mk, allow the user to set
my_copy_pairs to a list of src:dest pairs that will be copied into the
zip file.
Test: build-aosp_arm.ninja is identical before/after
Test: codesearch says that these variables aren't otherwise used
Test: set my_copy_pairs, ensure that they exist in the zip.
Change-Id: Ia80cd136db8ad37a71010baf0552621b281c8bc3
`make custom_images` supports to build different kinds of *non-droid* images,
e.g., odm.img. Adding the support of signing them with either AVB HASH footer
or AVB HASHTREE footer. The user can use HASH for small images and
HASHTREE for large images.
Sample signing configurations:
* AVB HASH footer:
- CUSTOM_IMAGE_AVB_HASH_ENABLE := true
- CUSTOM_IMAGE_AVB_ADD_HASH_FOOTER_ARGS := --append_to_release_string my_odm_image
* AVB HASHTREE footer:
- CUSTOM_IMAGE_AVB_HASHTREE_ENABLE := true
- CUSTOM_IMAGE_AVB_ADD_HASHTREE_FOOTER_ARGS := --fec_num_roots 8
* Using custom signing key:
- CUSTOM_IMAGE_AVB_ALGORITHM := SHA256_RSA2048
- CUSTOM_IMAGE_AVB_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
Bug: 36701014
Test: `make custom_images` with AVB HASH footer
Test: `make custom_images` with AVB HASHTREE footer
Test: `make droid` to check system.img is still properly signed with AVB HASHTREE
Test: `make droid` to check vendor.img is still properly signed with AVB HASHTREE
Change-Id: I8dc420e12e37e9a631345c0cd883339db05d489f
Set CUSTOM_IMAGE_AVB_ENABLE := true to enable avb, add_hashtree_footer
args can be added in CUSTOM_IMAGE_AVB_ADD_HASHTREE_FOOTER_ARGS.
Bug: 38319818
Test: m custom_images
Change-Id: Ia452dc5ce8b55bcbd3abba9e965b72e78fd8c104
HOST_OUT_EXECUTABLES is already added to the PATH variable,
so it is not needed to add the path info for binaries in
misc_info.txt and <partition>_image_info.txt.
Earlier the mkuserimg item in the build_image dictionary is
hardcoded to "mkuserimg.sh", but now it is customized for
mkuserimg.sh and mkuserimg_mke2fs.sh, and maintained in
dictionary "ext_mkuserimg=$(MKEXTUSERIMG)" in misc_info.txt
and <partition>_image_info.txt, where it is used in the
build_image script while creating the images.
The problem here is the value for this key is set to build
path of the file mkuserimg file
$(HOST_OUT_EXECUTABLES)/mkuserimg.sh,
i.e. out/host/linux_x86/bin/mkuserimg.sh,
there by standalone signing the images using otatools is
not working as the executables are packed in bin folder.
Test: tools/releasetools/sign_target_files_apks
-p <extracted ota-tools.zip folder>
--extra_signapk_args=-f /etc/opt/cert_data.dat
-v
--replace_verity_private_key ~/build/target/product/security/verity
--replace_verity_public_key ~/build/target/product/security/verity.x509.pem
-k <key maping>
<input target files zip>
<output target files zip>
Change-Id: I57af1025ec38f3794f779c49faa0bf965afc6a5d
New custom image configuration variables:
- CUSTOM_IMAGE_SELINUX, set to "true" if the image supports selinux.
- CUSTOM_IMAGE_SUPPORT_VERITY, set to "true" if the product supports verity.
- CUSTOM_IMAGE_VERITY_BLOCK_DEVICE
Also changed the staging directory name to the mount point, like we do
for other images built by the build system.
Bug: 19609718
Change-Id: I6bbf06b79eee63e4c77834f2e6f1d5a7f7e00a12
Build additional images requested by the product makefile.
This script gives the ability to build multiple additional images and
you can configure what modules/files to include in each image.
1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile.
PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles.
Each makefile configures an image.
For image configuration makefile foo/bar/xyz.mk, the built image
file name
will be xyz.img. So make sure they won't conflict.
2. In each image's configuration makefile, you can define variables:
- CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm"
etc.
- CUSTOM_IMAGE_PARTITION_SIZE
- CUSTOM_IMAGE_FILE_SYSTEM_TYPE
- CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary
accepted by BuildImage() in tools/releasetools/build_image.py.
- CUSTOM_IMAGE_MODULES, a list of module names you want to include
in the image; Not only the module itself will be installed to proper
path in the image, you can also piggyback additional files/directories
with the module's LOCAL_PICKUP_FILES.
- CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to
the image. <dest> is relativ to the root of the image.
To build all those images, run "make custom_images".
Bug: 19609718
Change-Id: Ic73587e08503a251be27797c7b00329716051927
