Some apk files, e.g. Chrome.apk has switched to use v2+ scheme.
And the apk file no longer has a META-INF/CERT.RSA. So, the
signature parsing script should use apksigner to dump the cert
info.
Leave the parsing of META-INF/CERT.RSA as a fallback, as some apks
fail the `apksigner verify`. The script also switches to store the
digest of the cert instead of the raw bytes.
Bug: 157735036
Test: run check_target_files_signatures on aosp|signed target-files
(cherry picked from commit a9a50cf6e3)
Change-Id: I910cd1aa91d1e446bef7097871af4171c285685d
Incremental OTA generation was failing since the
function _CheckSecondTokenNotSlotSuffixed was in
broken state, this change fixes the same.
Bug: 160215626
Test: Incremental OTA now gets generated and applied
successfully a non-ab device.
Change-Id: Ifb3886396fe65dcdaeba16c568419b9fa084193d
(cherry picked from commit 52defe48d52a770c326f489357ab8877b211541e)
Merged-In: Ifb3886396fe65dcdaeba16c568419b9fa084193d
Starting from http://go/aog/1328118, we chained the 1st GKI
boot image into vbmeta. However, this fails avb validation;
because the avbtool constructs the image path based by using
"partition name + ext".
This cl works around the issue by renaming boot-5.4.img to
boot.img, so avbtool can find the image correctly.
Bug: 159656873
Test: run validate target file
Change-Id: I577226596e139e5b5f3e6ca3c28ced02431ca392
Merged-Id: I577226596e139e5b5f3e6ca3c28ced02431ca392
(cherry picked from commit 5ec1a7a66a)
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
When calculating the dynamic fingerprints, we need to reopen the
input file if it's a ZipFile. Because the original object has been
closed, as its scope ends after the with statement.
Bug: 152167826
Test: generate an OTA package with zip input and overrides
Change-Id: I623da3cc5fcc91c6230fb5a6e86517ed995913b7
(cherry picked from commit eb06afb602)
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
The oem partition allows system build.prop to import properties from it
by "import /oem/oem.prop xxxx". An _ImportParser() error was raised on
this case.
BUG: 154171021
Test: 1) "atest --host releasetools_test releasetools_py3_test -c"
2) On a device who has oem partition, "make dist" and sign its
target zip file.
Change-Id: I47875bf7a698390e11690150e6516a3064550ca0
Merged-In: I47875bf7a698390e11690150e6516a3064550ca0
The values of the ro.boot* variables are not part of the image files
and are provided (e.g. by bootloaders) at runtime. Meanwhile, their
values may affect some of the device build properties, as a different
build.prop file can be imported by init during runtime.
This cl adds an option to accepts a list of possible values for some
boot variables. The OTA generation script later use these values to
calculate the alternative runtime fingerprints of the device; and
list the device names and fingerprints in the OTA package's metadata.
The OTA metadata is verified by the OTA server or recovery to ensure
the correct OTA package is used for update. We haven't made any
restrictions on what ro.boot* variables can be used for fingerprint
override. One possible candidate can be the skus listed in
ODM_MANIFEST_SKUS.
Bug: 152167826
Test: unittests pass, generate an OTA file with the new option
Change-Id: I637dea3472354236d2fd1ef0a3306712b3283c29
Merged-In: I637dea3472354236d2fd1ef0a3306712b3283c29
This reverts commit b21e48b499.
In practice, some partners use the 'import' statement to override
the device fingerprint at runtime. The runtime fingerprint will
later add to the metadata of OTA package, so that the OTA server
can deliver the package to corresponding devices correctly.
This CL supports parsing a subset of import statement that the init
process recognizes. And we loose the restriction based on how the
dynamic fingerprint is used in practice. Right now, we only searches
for the override of brand, name and device. And the placeholder
format should be ${placeholder}, with its value supplied by the
script caller.
As part of the implementation, we generate all the possible
combinations of the input boot variables. And recalculate the
fingerprint for each of the combination. Though we load the
build.prop multiple times, the logic is easier to follow. Also,
it's more convenient to enhance the logic if we only want to
allow some of the boot variables combination later.
Bug: 152167826
Change-Id: I4a9fa35c7ac037ff1cf4f9a4bdff602beac3894b
Merged-In: I4a9fa35c7ac037ff1cf4f9a4bdff602beac3894b
Test: unittests pass
This reverts commit 6022545272.
The build prop for a partition used to be a simple key:value
dictionary. But we need more fields to hold the alternative build
props overriden by the 'import' statement. Therefore, add a new
class as a wrapper for these props first.
Bug: 152167826
Change-Id: I5c952cd2a976ba1a09ddc66d56c2b8b55a61986b
Merged-In: I5c952cd2a976ba1a09ddc66d56c2b8b55a61986b
Test: unittests pass
avb_extra_custom_image_extra_args can be set to
'oem=--signing_helper_with_files=/tmp/avbsigner.sh' on signing server.
The second '=' shouldn't be splitted in this case.
BUG: 154171021
Test: Manually sign target zip files which has 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="--signing_helper_with_files=/tmp/avbsigner.sh" \
xxxx-target_files.zip signed.zip
Change-Id: I815d574f791734d4c6a25a9f8d827b5b4f93d7cc
Merged-In: I815d574f791734d4c6a25a9f8d827b5b4f93d7cc
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
When sign_apex.py re-signs an apex, the hash algorithm is extracted and
it is used when re-packaging the file.
Bug: 155771970
Test: releasetools_py3_test doesn't regress
(some tests were failed, but they failed even without this change:
test_ApexApkSigner_apkKeyNotPresent (test_apex_utils.ApexUtilsTest) ... ERROR
test_ApexApkSigner_noApkPresent (test_apex_utils.ApexUtilsTest) ... ERROR
test_ApexApkSigner_noAssetDir (test_apex_utils.ApexUtilsTest) ... ERROR
test_ApexApkSigner_signApk (test_apex_utils.ApexUtilsTest) ... ERROR)
Merged-In: I996a33e0208d3dd3a04a31b8dafb27ef995297f2
Change-Id: I996a33e0208d3dd3a04a31b8dafb27ef995297f2
(cherry picked from commit a1887f326c)
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
We recently modify the logic in install-recovery.sh to support
non-A/B updates on VAB launched devices. And the position of the
$(getprop ro.boot.slot_suffix) is misplaced for the recovery image.
For example:
"if ! applypatch --check EMMC$(getprop ro.boot.slot_suffix):/dev/block/recovery:SHA1"
should be:
"if ! applypatch --check EMMC:/dev/block/recovery$(getprop ro.boot.slot_suffix):SHA1"
Bug: 156979431
Test: rerun add_image_to_target_file, then validate_target_files
Change-Id: Id2d45e281151a46d66b37ea8fdb7b5cb4ae72e81
The secondary payload is used by factory OTA to speed up the first
boot of the device. The payload should only contain bootloaders
images and the precompiled apps in system_other. Remove vendor_boot
to reduce the secondary payload size.
Bug: 156782745
Test: build a package with secondary payload
Change-Id: I3a9f6dda00a5aac038438065e2bc6483d71b5e95
(cherry picked from commit c385064d94)
* common.py requires the signapk jar
Bug: 156149605
Test: m otapackage ( before it was broken )
Change-Id: Ic0cff0a21258cb1e7d1ced5553a940dcf5cd6d04
Merged-In: Ic0cff0a21258cb1e7d1ced5553a940dcf5cd6d04
Whenever a device is retrieved from fstab, wrap it with
add_slot_suffix() if it has slotselect option.
Test: change fstab (changes boot image, which is a static partition),
change system partition (a dynamic partition),
generate incremental OTA with --force_non_ab and apply it on
cuttlefish
Bug: 153581609
Change-Id: Id3f8e4425b65176baf1b0ff1ee07ab3d820a3a7f
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
For older target_files.zip, since "recovery_mkbootimg_args" may not be
set fallback to the earlier config -"mkbootimg_args" for recovery image.
This will make releasetools backward compatible, and usable for
older/already generated target-files package.
Bug: 155708400
Change-Id: If40359130b8e6da48cb8c345d8cb079f457fe36f
Merged-In: If40359130b8e6da48cb8c345d8cb079f457fe36f
The oem_dicts in BuildInfo is only available to ota_from_target_files
when it's called with "--oem_settings" input. However, aosp/1135332
starts to use BuildInfo in add_img_to_target_files w/o oem_dicts. An
assert is triggered due to it when oem_fingerprint_properties is in the
info_dict.
This change skips _oem_props reading if oem_dicts is None to allow this
case.
BUG: 155360923
BUG: 154171021
Test: Sign images with oem_fingerprint_properties.
Change-Id: I6a73feecd9567fd4d85f4eab3d4e11c5df28fe39
Merged-In: Idfd41c8b20b23d50e4895f24500f9a25625b7d98
When loading build info from a previous version of Android, the set of
allowed property sources should match those available in that version.
In this particular case, the product_services partition was a valid
property source in Android 10.
Bug: 155053195
Test: ran unit tests from test_common.py
Test: generated an incremental OTA which previously failed
Change-Id: Ic0b0a112656533eca78dee31517deff7e3c8d7cc
Merged-In: Ic0b0a112656533eca78dee31517deff7e3c8d7cc
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
Add support for building a non-v3 recovery image along with a
v3 boot.img and vendor_boot image.
Bug: 150825361
Change-Id: I80d4e71ff09b83dd1c7f9accb4de99a30f95f4bf
Merged-In: I80d4e71ff09b83dd1c7f9accb4de99a30f95f4bf
Since we might use ToT release tools to sign a package
generated by an older build, we make the new
`partition=` tag optional. This also means we need to be
careful to use non-greedy regex matching.
Bug: 153133823
Test: python3 -m unittest
Test: input with and without the new `partition=` tag
Test: new test_ReadApkCerts_WithWithoutOptionalFields
Change-Id: Ic57efd34e745ad302ae17150c6f2318f0b4524cb
Merged-In: Ic57efd34e745ad302ae17150c6f2318f0b4524cb
Propagate partition tag data to apexkeys.txt and
apkcerts.txt so that merge_target_files.py can build
merged versions of these files by filtering the
framework files for framework partitions and filtering
the vendor files for vendor partitions.
Bug: 138942268
Change-Id: Ic3226728e97dae84d38ec230ccc86d1b124bea94
Merged-In: Ic3226728e97dae84d38ec230ccc86d1b124bea94
When doing apk-in-apex signing, the package name is not reserved
during the apex repacking. As a result, the name accidentally
reverts to 'com.android.wifi' from 'com.google.android.wifi'.
This cl changes the behavior to call 'apexer' by passing the
'--payload_only' argument. So we don't build the apex file from
scratch and the old AndroidManifest.xml will be reused.
BUG: 152084536
Test: unit tests pass
Change-Id: I8332b2ee84832fb196f2e1c4309abac5ab92e153
Merged-In: I8332b2ee84832fb196f2e1c4309abac5ab92e153
In the case when both ODM_MANIFEST_SKUS and ODM_MANIFEST_FILE are
both empty, also checks VINTF compatibility for empty SKU case.
Same for device manifest. Although right now, DEVICE_MANIFEST_FILE and
DEVICE_MANIFEST_SKUS cannot be both empty (because libvintf requires
vendor manifest exists barring manifest fragments), let libvintf throws
an error for this case. In the build system, simply handle vendor manifest
the same way as ODM manifest.
Fixes: 148601741
Test: manual
Change-Id: Ia0655fd4d37f6286b164a3221ec4b2716f29147d
Merged-In: Ia0655fd4d37f6286b164a3221ec4b2716f29147d
If DEVICE_MANIFEST_FILE / ODM_MANIFEST_FILES is set, also include check
for empty vendor / odm SKU, respectively. Then, do cross product of
vendor SKUs and ODM skus, and check each possible combination.
Test: build with and without vendor skus
Test: m check-vintf-all
Bug: 148601741
Change-Id: I23cc81998e7afc36c43540bf6d615b4d4b288447
Merged-In: I23cc81998e7afc36c43540bf6d615b4d4b288447
Problem:
Logical partitions do not update right since commit
f67dd8059d
Generate block based OTA for product partitions
due to the wrong order of parameters. This is logged in
/tmp/recovery.log:
skipping 0 blocks already patched to 202
Test: build
Bug: 149794632
Change-Id: I92f7a8a226a8a96b892254362d362c515bfb6dc6
(cherry picked from commit 2a7aaa69ae)
This causes the output image files of a merged build to be identical
to the image files of the input partial builds, for each images in
PARTITIONS_WITH_CARE_MAP.
Test: python -m unittest test_common
Test: `m dist`; `unzip out/dist/target_files.zip IMAGES/\*`;
`zip -d out/dist/target_files.zip IMAGES/\*`
`add_img_to_target_files -a out/dist/target_files.zip`.
Verify that the rebuilt images are identical to the deleted ones.
Test: Build a merged target (using merge_target_files.py). Verify that
the partial target-files.zip IMAGES are identical to the merged
target-files.zip IMAGES for PARTITIONS_WITH_CARE_MAP images.
Bug: 150405807
Change-Id: I5fdf5783c1aff9c14cf5408090389b1f65b69ca6
(cherry picked from commit d5fe862628)
AVB public keys might be installed into the first-stage ramdisk.
This CL supports removing some AVB keys during the signing process,
which can be useful when a key needs to be revoked.
Also correcting the path of force_debuggable detection.
Bug: 150109393
Test: make dist
Test: ./build/tools/releasetools/sign_target_files_apks \
--remove_avb_public_keys key1.avbpubkey,key2.avbpubkey \
out/dist/*-target_files-*.zip signed-target_files.zip
Change-Id: I1af95adbbec655f40121f3392965dd1950aca4e5
Merged-In: I1af95adbbec655f40121f3392965dd1950aca4e5
(cherry picked from commit 2fe786a528)
The monotonic property of the range is lost after the recent change to
subtract 0th block from the file range. As a result, we read the block
in the wrong order when pull files from the raw image. This yields a
incorrect hash during validation.
Bug: 150334561
Test: run validate_target_file. unittests
Change-Id: Id4fedaaf273c42c8d21a4549fda4c9a45e22066a
(cherry picked from commit f02ececc7f)
e2fsdroid can export holes as a "0" block, in order to make sure logical
and physical block assignments are maintained properly. Exclude these
hole blocks from range sets in LoadFileBlockMap.
Bug: 139201772
Test: m dist on non-A/B
Change-Id: Ic04e869572229678fdeaaa6fbf6f464d6c672051
Regardless of the value of "ext4_share_dup_blocks" "-c" flag is passed
unconditionally. The correct behavior is to check if
"ext4_share_dup_blocks" is set to "true".
Test: 1. build bonito with "BOARD_EXT4_SHARE_DUP_BLOCKS := false"
2. check for "shared_blocks" feature of system.img
./out/host/linux-x86/bin/tune2fs -l \
./out/target/product/bonito/system.img | \
grep -o shared_blocks
Change-Id: I8c0e5606658dd0f47b71cfc6c453a77a57da4f42
If a key is specified, the avbtool always use the input key to verify
all the chained images. And this will cause failures when the vbmeta &
system use different keys (e.g. RSA 4096 vs RSA2048). Because the public
key to vbmeta will always fail to verify the system image. Remove the
'--key' parameter in the verification command, so the avbtool will use
the embedded public in the image.
Test: validate target-file from sdk_gphone_x86_64
Bug: 148916990
Change-Id: I9d31be0f8c32af605af94fa73d07818f40f51ec4
We should add quote when passing the signing arguments to apexer. So
the final argument whould look like
apexer ... --signing_args "--signing_helper_with_files=%path"
And the argument parser in avbtool will eventually parse the
"--signing_helper_with_files" correctly.
Bug: 148627666
Test: unittest pass, run a smoke sign_target_files_apk with signing arguments
Change-Id: Ie203d26a508cb98ca94e6c364a2640b681ad79f2
In the build signing environment, we don't necessary have access to the
physical private key. And we work around it by passing an extra
signing_helper to the avbtool instead of a private key. Since we need
to perform signing to add the hashtree footer when rebuilding the apex
image. We should propogate the signing_helper to apexer and eventually
to avbtool.
Bug: 148627666
Test: unit tests pass. Smoke test by pass a public key to apexer and
hardcode the private key in signing helper script.
Change-Id: I56d57485493a5ba2cbe4c49e493ee9604f68088b
Tianjie