Allow dm-verity to be enabled without boot and recovery images being
signed. This makes it possible to enable only dm-verity to detect
corruption without confusing bootloaders that do not understand signed
images.
Bug: 19985143
Change-Id: Ie52c6ff595faa7a5c1f1bc1b37f6899c4d0c7001
Add vboot properties to the dictionary file, which will be packed into
the target_files zip. Add support in packaging and OTA scripts to
sign the generated bootable images (boot.img and recovery.img) when
vboot is enabled.
Change-Id: I08758ced03d173219415bca762bbdb66c464a9f5
(cherry picked from commit 5d5a3bd9e8d8b14b71d1b2105417a2958d13d3d2)
Added support to build system.img that combines contents of /system and
the ramdisk, and can be mounted at the root of the file system.
To enable this feature, define BoardConfig.mk variable:
BOARD_BUILD_SYSTEM_ROOT_IMAGE := true
Ideally we would just change TARGET_OUT (the path of the staging system
directory) to under TARGET_ROOT_OUT. But at this point many places in
the build system assume TARGET_OUT is independent of TARGET_ROOT_OUT and
we can't make it easily configurable.
Instead this implementation takes the least intrusive approach:
We don't change TARGET_OUT or TARGET_ROOT_OUT. We just assemble a
temporary staging directory that contains contents of both TARGET_OUT
and TARGET_ROOT_OUT, in build_image.BuildImage() of
tools/releasetools/build_image.py.
When build_image.py is directly called from the makefile, we pass in the
parameters from the global dictionary; when build_image.BuildImage() is
called from add_img_to_target_files.py, we need to override values to
point to files extracted from the target_files zip file.
We need to combine the fs_config files of both /system and ramdisk,
when fs_config is enabled.
Also this change refactored build_image.BuildImage() by moving the extra
parameters to the image property dictionary.
(cherry-picked from commit 0eabd4f2c5)
Bug:19868522
Change-Id: Iafc467a0e3427b0d6ad3b575abcc98ddcc9ea0f1
Added support to build system.img that combines contents of /system and
the ramdisk, and can be mounted at the root of the file system.
To enable this feature, define BoardConfig.mk variable:
BOARD_BUILD_SYSTEM_ROOT_IMAGE := true
Ideally we would just change TARGET_OUT (the path of the staging system
directory) to under TARGET_ROOT_OUT. But at this point many places in
the build system assume TARGET_OUT is independent of TARGET_ROOT_OUT and
we can't make it easily configurable.
Instead this implementation takes the least intrusive approach:
We don't change TARGET_OUT or TARGET_ROOT_OUT. We just assemble a
temporary staging directory that contains contents of both TARGET_OUT
and TARGET_ROOT_OUT, in build_image.BuildImage() of
tools/releasetools/build_image.py.
When build_image.py is directly called from the makefile, we pass in the
parameters from the global dictionary; when build_image.BuildImage() is
called from add_img_to_target_files.py, we need to override values to
point to files extracted from the target_files zip file.
We need to combine the fs_config files of both /system and ramdisk,
when fs_config is enabled.
Also this change refactored build_image.BuildImage() by moving the extra
parameters to the image property dictionary.
Bug:19868522
Change-Id: Iafc467a0e3427b0d6ad3b575abcc98ddcc9ea0f1
This caught a few bugs/syntax errors (a few character classes were not
escaped properly in regex patterns, some indentation was illegal,
etc).
Change-Id: I50637607524e68c4fb9cad7167f58a46b8d26b2c
We need to patch zipfile during close() too, because it refers to the
ZIP64 file size threshold when writing out the central directory
Bug: 18015246
Bug: 19888174
Change-Id: I1b49d653d0831fcc2106808f86c929d7a2b22ff3
Signed-off-by: Greg Hackmann <ghackmann@google.com>
The generated OTAs are supposed to be repeatable. The use of dict in
blockimgdiff.py breaks the assumption for block-based OTAs. Fixed by
using OrderedDict instead.
Change-Id: I945bdc879912ba174ca330c152b1f8fc7ed211ac
Python 2.7's zipfile implementation wrongly thinks that zip64 is
required for files larger than 2GiB. We can work around this by
adjusting their limit. Note that `zipfile.writestr()` will not work
for strings larger than 2GiB. The Python interpreter sometimes rejects
strings that large (though it isn't clear to me exactly what
circumstances cause this). `zipfile.write()` must be used directly to
work around this.
This mess can be avoided if we port to python3.
The bug (b/19364241) in original commit has been fixed.
Bug: 18015246
Bug: 19364241
Bug: 19839468
(cherry picked from commit cd082d4bfe)
Change-Id: I7b5cc310e0a9ba894533b53cb998afd5ce96d8c6
BlockImageDiff has three versions. Only the incremental OTAs generated
with the latest version (3) can be re-applied to the system that's
already on the target build. Otherwise, operations like move will make
unconditional changes and damage the system. During the verification
phase, abort the OTA update if BlockImageDiff is less than 3 and it
doesn't match the checksum of the source build.
Change-Id: Iaf834a2d99dfea0bb423a4a2aa09e8906424482d
(cherry picked from commit daebaa6ed3)
BlockImageDiff has three versions. Only the incremental OTAs generated
with the latest version (3) can be re-applied to the system that's
already on the target build. Otherwise, operations like move will make
unconditional changes and damage the system. During the verification
phase, abort the OTA update if BlockImageDiff is less than 3 and it
doesn't match the checksum of the source build.
Change-Id: Ic630346eab2a993a84d0aeaacd7167ef62cc24f6
(cherry picked from commit daebaa6ed3)
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 will only be used when the block file format is at least
version 3. For V1/V2 (L, L MR1) block versions, fall back to
the old range_sha1 check.
Bug: 19357591
Change-Id: I7cb178b70d48ec3c98cdb88ed1c94cf7797a01d0
(cherry picked from commit cad78c12fb)
