add_img_to_target_files.py
See bug description:
"When resigning images, the validate_target_files.py can be used to
verify the images using avbtool. The script will use the vbmeta.img to
achieve this, and all relevant images need to be in the IMAGES folder.
However, due to changes on add_img_to_target_files.py and specifically
the commit 5277d1015, some images (e.g. acpio.img and tos.img) are no
longer copied from RADIO to the IMAGES folder. This causes an error on
validate_target_files.py indicating that it cannot find image such as
IMAGES/acpio.img."
This CL fixes this by symlink images under RADIO directory to IMAGES
directory before invoking avbtool.
Bug: 159299583
Test: python3 -m unittest test_validate_target_files
Change-Id: I5769ee2ab5230d2a3a7cef10706dcc5788e654f8
Merged-In: I5769ee2ab5230d2a3a7cef10706dcc5788e654f8
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
Bug: 141258651
Change-Id: Iea50b6bd9af9452a2600c97e2f7cb89218b9be7f
(cherry picked from commit 5e9e1fbe83)
Merged-In: Iea50b6bd9af9452a2600c97e2f7cb89218b9be7f
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
* changes:
Add an option to input the boot variables for OTA package generation
Reland "Calculate the runtime fingerprint prefixes from build prop"
Reland "Add a wrapper class PartitionBuildProp""
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
placeholder
Bug: 134509111
Test: add "test_mainline_modules: [some.apk]" to TetheringTests,
and build the modules, confirm the parameterized option is added
in the test config.
Change-Id: I0f4f837412075520153d21c9ca12cf5c3f555de7
Merged-In: I0f4f837412075520153d21c9ca12cf5c3f555de7
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
As we move towards becoming a Mainline module, it's important that
we catch as many bugs as possible during initial code review, and
Error Prone is designed to do exactly that.
Instead of lumping ourselves into the generic "packages" grouping,
this change adds a specific package for this Mainline module.
Bug: 142561358
Test: ./build/soong/soong_ui.bash --make-mode MediaProviderLegacy com.google.android.mediaprovider MediaProviderTests RUN_ERROR_PRONE=true
Change-Id: I62102febe39225a54c77d9ad463c350b3df9cafa
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
Also add multi-cert support to prebuilt apps so that they can benefit
from the new lineage feature.
Test: m GoogleServicesFramework w/ modified build rules
Test: m PrebuiltGmsCore w/ modified build rules
Test: apksigner lineage -v --print-certs -in <built_module_path>
Fixes: 152897457
Change-Id: If7d5d4bd308629c8340231520214c76c8a568a65
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
If this flag is enabled, the v4 signature file, named [outputApkFile].idsig
will be generated along side the outputApkFile.
Test: atest PackageManagerShellCommandIncrementalTest
BUG: 149354175
Change-Id: I5bc78bbc8b666a490f3ab05e781bfd859575af58
