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
(cherry picked from commit 5fcf1094f9)
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
This allows developers to build the test packages individually without
needing to build the entire CTS release.
bug: 18945639
Change-Id: Iedc162059617f683a16a6b80cb7b1a6e0674bba4
It's pain to maintain an inactive product's list of
PRODUCT_FACTORY_RAMDISK_MODULES or PRODUCT_FACTORY_BUNDLE_MODULES.
Just show a warning if a module name becomes dangling.
Bug: 18779515
Change-Id: I3d137ed59feb005b186ed2a3519465da3d8f45c3
Fix an issue where the add-on system images have 2 extra
inner folders. The sole root folder in the zip file should
be the ABI one.
Change-Id: Ie12b913438e2b1113d34222e467ff280daa23c7f
With split apk support, we may have multilple installed files for a
module. Use ALL_MODULES.$(module).BUILT_INSTALLED to make sure get
every split apk included.
Bug: 16947729
Change-Id: I4e41c2586f1b25f4810b67cd1e948aba0cbcf97b
The whitelist is a preconfigured list of regular expressions of package
names.
Run the check as a task by default in platform build.
Bug: 17434570
Change-Id: Ieaaf7efb5f4fc7a83677f3675780ca902972be97
Change the add-on build rules to packages the system-image
separately from the main add-on zip file. This is then picked
up by development's sdk_repo.mk to generate two repository
packages files (one for the add-on, one for its system image.)
The system-image now also contains a source.propertie file,
which value is not infered from the add-on's manifest.ini
Add-on product files need to be modified to define a
PRODUCT_SDK_ADDON_SYS_IMG_SOURCE_PROP variable that points
to their source.properties or source.prop_template file.
Change-Id: I79e9cdfd43c99f099a70890fb3e5e9215ad647f4
- This simplifies the logic to get the mapping of built-file to
installed-file. Previously we used file suffix matching which is error
prone and not scalable.
- With this change the .odex files will be included automatically.
Bug: 13585955
Change-Id: I4599abf93b9d501bac7aca7758d7f3aee21b3e36
