The former comment no longer applies, as we have been always packing
META/file_contexts.bin in a target_files.zip (commit aa7318c3, since
Nougat), and we no longer look for the one under BOOT/RAMDISK/ (commit
d14b8956, since Q).
Test: N/A
Change-Id: I03f361234bf440e942f21e5a624862590248544b
This file is used by OTA generation so it needs to appear in mixed
builds with the combined content from the system and other versions of
the file.
Test: python -m unittest test_merge_target_files
Test: Running merge_target_files on a dynamic-partition-enabled build
and observing the resulting target files.
Bug: 131889742
Change-Id: I4ddbebc087e430f6307d0bd5461121a374e58ea4
Bug: 123428770
Test: Built system-only image and checked that no boot.img or
recovery.img files where created. Booted the resulting merged build on
device.
Change-Id: I760476502775e68125907c39e66b8665e789a798
The old process_file_contexts_bin function did not properly generate a usable
file_contexts.bin to regenerate images, so instead use the file_contexts.bin
from the other partial target files package. When combining any one of several
other partial target files packages with a single system partial target files
package, this file will properly apply contexts as long as the same source is
used for the system partial target files.
Test: Verify that file contexts are properlty applied to vendor image.
Bug: 131584454
Change-Id: I16f8cc3b7f2eb7f09746f0ddcb2c1daf3fd19da6
Some properties had 'test-keys' still set
after signing the target files zip for release.
These properties are now added to the RewriteProps
method.
Bug: 131810966
Test: manual
Test: `atest releasetools_test`
Change-Id: Ifb352ed28f5100f1e9f686d77e935723f7f6d3ae
common.GetCareMap() may return an empty list on unavailable care_map
since the change in commit 8bdfb990ea.
Caller needs to handle such a case accordingly. This CL fixes the caller
in add_img_to_target_files.py, and changes the return value to None to
break legacy callers loudly.
Fixes: 131794385
Test: `atest releasetools_test`
Change-Id: I7c94f456064199237e84ef75732bdd10ebe31736
When set, product-img-tag.zip contains super.img instead of individual
user images from target files. For virtual devices, super.img is needed
to boot the device, but individual user images aren't needed.
Test: on A/B DAP, with flag set:
- m updatepackage and look at img.zip
- img_from_target_files
both have super.img and not system / vendor / system_other
Test: on non-A/B DAP, with the flag set:
- m updatepackage and look at img.zip
- img_from_target_files
both have super.img and not system / vendor
Test: on A/B retrofit, with the flag set:
- m updatepackage and look at img.zip
- img_from_target_files
both have super_*.img and system_other.img, but not system / vendor
Bug: 113175337
Change-Id: I94e33091d0c837cae40776176b4dcfdd338aba90
When odm is changed, device manifest/matrices should be included.
When product is changed, framework manifest/matrices should be included.
Bug: 130714844
Bug: 126770403
Test: build with odm and product VINTF metadata
Change-Id: I49c8083e0e7185ae7b96047d68f1f624b1113dfc
Test: `atest --host releasetools_test`
Test: `m dist` with a target that uses non-sparse images.
Test: Run UpdateVerifierTest on blueline.
Change-Id: I8fdebee42fcaac78c2d1be2a84ddb69f46ec701d
For an PRESIGNED APEX, it has the following format, which should be
considered as a valid input.
name="foo.apex" public_key="PRESIGNED" private_key="PRESIGNED" container_certificate="PRESIGNED" container_private_key="PRESIGNED"
Bug: 131153746
Test: Run sign_target_files_apks.py on a target_files.zip with PRESIGNED
APEXes.
Test: python -m unittest sign_target_files_apks
Change-Id: I51076b0c6eddfb75637d37659a08009f0a88e931
By sorting the content of the final output merged target files package, the
merged target files package is more like the target files packages generated by
a build.
Test: Generate merged target files package, verify that content is sorted.
Change-Id: Ic0c198630ebd7692a3f3f9663d85e4b45229175c
We used to require explicitly setting both (e.g. `-e foo.apex=` and
`--extra_apex_payload_key foo.apex=` to skip signing `foo.apex`).
This CL allows specifying `-e` alone to achieve the same result.
However, if a conflicting `--extra_apex_payload_key` is also specified,
that would be considered as a config error.
Bug: 131153746
Test: Run sign_target_files_apks.py with `-e foo.apex=` alone to skip
signing foo.apex.
Test: Run sign_target_files_apks.py with `-e foo.apex=` and
`--extra_apex_payload_key foo.apex=key` and expect assertion error.
Change-Id: Ia747f59ee726b60bdb1445024e749320171064c2
This is used by merge_target_files to prevent an unnecessary unzip and
copy.
Test: Ran merge_target_files.py and booted using the img.zip.
Change-Id: I6fe0dd025b30b3f4965c9b22fb6943019bf5899b
The boot-debug.img should NOT be release signed and can only be used
if the device is unlocked. Adding a check to prevent the tool from
signing this debuggable boot.img.
See the following for more details about boot-debug.img:
https://android-review.googlesource.com/c/platform/build/+/947857
Bug: 126493225
Test: put a file /force_debuggable into boot.img, checks the following
command fails:
./build/tools/releasetools/sign_target_files_apks \
out/dist/*-target_files-*.zip signed-target_files.zip
Change-Id: Ia5232949cb9582d2b4eaa171d9e9f3fe7317d418
It's a vendor-specific property, which was historically included into
/system/build.prop prior to this change.
Whether a target uses A/B OTA shouldn't affect anything on the system
image, including the `ro.build_ab_update` property. Moving it to vendor
partition will also make it consistent with other A/B specific configs,
such as the `slotselect` flag in device fstab
(/vendor/etc/fstab.$(PRODUCT_PLATFORM)).
Bug: 130516531
Test: Build and flash crosshatch-userdebug. Check /system/build.prop,
/vendor/build.prop and the runtime property.
Change-Id: I927625fbcc02c4a875a1f39850b51576f5ff6c66
This simplifies the use case for mixed build users. Instead of having to
remember to call img_from_target_files.py after this script, they can
use this flag to automatically create the IMG package.
Also includes an update to super_empty.img logic. The super_empty.img is
now always created for dynamic-partition builds. The flag now only
controls copying the super_empty.img to a user-provided location.
Bug: 129976345
Test: Ran merge_target_files.py using --output-img and
--output-super-empty and inspected the resulting img zip and
super_empty.img.
Change-Id: Ida602942bb7a6b4b94f4e225640af9104fc9360c
Bug: 130787336
Test: m oemaids_header_gen oemaids_headers passwd group
Test: Set TARGET_FS_CONFIG_GEN to a list of paths
Change-Id: I5186b378fea8865f46cfd891420ba576f36e2565
This simplifies the use case for mixed build users. Instead of having to
remember to call ota_from_target_files.py after this script, they can
use this flag to automatically create the OTA package.
Bug: 129976345
Test: Ran merge_target_files.py using --output-ota and inspected the
resulting zip.
Change-Id: Icc95943c24b8f83b3221e845a7d69a34c1edb4fc
Any mixed build that uses dynamic partitions will require a
super_empty.img image. This image must be created from the merged
misc_info.txt file, so adding this functionality here simplifies
the creation of this image for users (versus having to call
build_super_image.py manually after calling merge_target_files.py).
Bug: 129976345
Test: Ran merge_target_files.py on a dynamic partition enabled build
using the new --output-super-empty flag.
Change-Id: I73901f363d73c9fae1af1579faa2a908369dbbec
This provides the ability to run merge_target_files without the end goal
of a target files zip. This is useful for users that only want the IMAGES
folder, for example.
Bug: 130304869
Test: python -m unittest test_merge_target_files
Change-Id: If0412b8e1eb85fe09d7b689fd7f56ce84067faea
They used to be disabled due to the assertion of search_path in setUp()
function, which is not a prerequisite for most of the tests.
Bug: 112080715
Test: `atest releasetools_test`
Test: TreeHugger
Change-Id: I3cbaf42aa09dba0b87a64e11d97de9b3f7af7a47
FileImage needs to be thread-safe because multiple
threads gets data from it when an incremental OTA
package is created.
Test: apply incremental OTA on cuttlefish
Bug: 113175337
Change-Id: I31637fce0fbd66f3fa6c5c478da09bae65a52229
About half of the testcases rely on external tools (i.e. the ones in
`otatools.zip`, which are external to releasetools module, but still
built by Android). It's WAI as releasetools scripts are mostly for
gluing purpose.
However, the current support in Soong doesn't allow packing the helper
modules as part of the built releasetools_test. This CL adds a decorator
that allows declaring external dependencies in testcases, which will be
skipped while running in presubmit. It doesn't affect local invocation
of `atest releasetools_test`.
Fixes: 112080715
Test: `atest releasetools_test`
Test: TreeHugger; check that releasetools_test is invoked (and test
passes).
Change-Id: I8fdeb6549023cf5ddeb79d610c7c37cf9f13d3cc
All the unittests will be built into releasetools_test. One can run the
tests with `atest releasetools_test` or the traditional way
`test_utils.py`. The atest way is recommended, which additionally builds
the required tools.
With the current support in Soong, we can't pack the built tools into
releasetools_test yet. So running `releasetools_test` alone in clound
would fail. Follow-up CLs will address the issue in order to deploy the
tests with TEST_MAPPING.
Bug: 112080715
Test: `atest releasetools_test`
Change-Id: Ica95517a5ab326f4e58fc57c6c2c276cfe882f3c
The function used to be serving system and vendor partitions only (as
they were the only partitions using sparse image at the point). The code
itself doesn't rely on anything specific to system/vendor.
Test: python -m unittest test_common
Change-Id: Ia4ecdeedb262f3d9db082128eaf9bab299983333
The signature size will be 512 bytes when signing the payload
with 4096 bits key. This cl determines the key size with
"openssl rsa -modulus"
The new key in testdata is generated by
"openssl genrsa -out testkey 4096"
Bug: 129163830
Test: generate and verify an OTA package
Change-Id: I6662b0a0c553dc0fd84711312a1256b887e332fd
* changes:
Only assert-max-image-size for static partitions.
sparse_img.py --get_partition_size return size of partition
Revert "Fix dynamic partition size check for devices with recovery"
assert-max-image-size doesn't make sense for
dynamic partitions, as build_image.py always find the
right size for the output image. Hence:
- build_image.py no longer need to write generated_*_info.txt
(which contains the size of the image).
- assert-max-image-size on the static BOARD_*IMAGE_PARTITION_SIZE. If
a partition is dynamic, that variable isn't set, and
assert-max-image-size becomes a no-op. If the partition is static,
assert-max-image-size checks the static partition size as it used
to be.
- Fix read-size-of-partitions to use the size of the partition by
reading the image directly (instead of using generated_*_info.txt).
For devices without AVB, with DAP enabled, and does not have
RESERVED_SIZE for partitions, because of right sizing, the original
code always warns about approaching size limits. Since such checks
doesn't make sense for dynamic partitions, remove them.
Test: builds on device with dynamic partitions
Test: builds on cuttlefish with DAP enabled (without AVB), no
more size limit warnings:
WARNING: out/target/product/vsoc_x86/vendor.img approaching size limit (X now; limit X)
Fixes: 122377935
Change-Id: I75e1b8322197cb18cf397d02aefd49d777bb6405
Also, move code from build_super_image.py to sparse_img.py.
Test: sparse_img.py on sparse and non-sparse images
Bug: 122377935
Change-Id: Ie91fdfdbb54298ea27eb20d1b5363aeb1470356e
If TARGET_USERIMAGES_SPARSE_EXT_DISABLED is set, don't provide
--sparse to lpmake, so that a non-sparse super image is built.
Test: build with the flag set.
Fixes: 120041578
Change-Id: I5a26e4c793b0e2ddc89e9c38c8828ac21044e78a
