The line was unintentionally removed in commit 7f804ba.
Test: ota_from_target_files.py generates a full OTA. Check the package
metadata.
Change-Id: Icae88e2a9bb2bfc450a3d0d7ab524d6a6eac9df5
BBOTA v1 and v2 (introduced in L and L MR1 respectively) don't support
resumable OTA. We shouldn't generate packages using v1/v2 at the risk of
bricking devices.
BBOTA v3 (since M) and v4 (since N) both support resumable OTAs. BBOTA
v4 additionally supports using FEC to possibly recover a corrupted
image.
Bug: 33694730
Test: Generate full and incremental OTAs w/ and w/o the CL. They should
give identical packages (in v4).
Change-Id: Ib89d9cd63ba08e8e9aa4131bed18876b89d244c0
Remove the following functions that are needed for file-based OTAs only:
- SetPermissions()
- SetPermissionsRecursive()
- MakeSymlinks()
- DeleteFiles()
- DeleteFilesIfNotMatching()
- RenameFiles()
- SkipNextActionIfTargetExists()
Bug: 35853185
Test: Verified there's no reference to these functions.
Change-Id: Iff24a9d705476211effaef28eed2a147fa5fcbce
In addition to the current behavior of add_img_to_target_files working
on an existing zip file, allow passing in a directory where the target
files have already been extracted. When in this mode, it writes the
images out to that directory instead of the zip file.
This allows us to call add_img_to_target_files on the temp directory
used during the build to create the target files package, saving the
time and space of unzipping what we just zipped. This also allows us to
use the parallel soong_zip, which compresses the images much faster.
Test: aosp_marlin target_files zip is the same before/after this change
Test: marlin target_files zip is the same before/after this change
Test: bullhead target_files zip is the same before/after this change
Change-Id: I155654cdc7ad7754ba4ef76ec69c31f504a58198
We have stopped shipping devices with file-based OTAs, and are not
actively maintaining the support. Devices using file-based OTAs
should be moved to block-based, if not A/B OTAs.
We will also need to clean up EdifyGenerator class, which will be
handled in follow-up CLs.
Bug: 35853185
Test: Generate full and incremental OTAs w/ and w/o the CL, and they
give identical packages.
Test: Not specifying --block also generates block-base OTAs.
Change-Id: I3b0fc8ce5600e109f3251fe41f655534aaa298c7
We must have created the images (system.img, system.map etc) prior to
calling ota_from_target_files.py (added by commit
2e0d8fcf08, into Lollipop).
Remove the obsolete suppport for handling "old" target_files zips that
don't have such images. This simplies the logic for BuildSystem() and
BuildVendor(), which now would only be called by
add_img_to_target_files.py itself.
Test: Generating full and incremental OTAs give the same results, w/ and
w/o this CL.
Change-Id: I0ea243d09d3378249d7982701ae4ec339b04b7b8
The first one in WriteVerifyPackage() is mismatching function parameters
that can be trivially fixed.
The other one is in WriteABOTAPackageWithBrilloScript(), where we don't
have edify script instance.
Test: `pylint --rcfile=pylintrc ota_from_target_files.py`.
Change-Id: Ie238ef5b296dfe9e725b61376992447b662d2376
The major issue with the existing implementation is unnecessarily
holding too much data in memory, such as HashBlocks() which first reads
in *all* the data to a list before hashing. We can leverage generator
functions to stream such operations.
This CL makes the following changes to reduce the peak memory use.
- Adding RangeSha1() and WriteRangeDataToFd() to Image classes. These
functions perform the operations on-the-fly.
- Caching the computed SHA-1 values for a Transfer instance.
As a result, this CL reduces the peak memory use by ~80% (e.g. reducing
from 5.85GB to 1.16GB for the same incremental, as shown by "Maximum
resident set size" from `/usr/bin/time -v`). It also effectively
improves the (package generation) performance by ~30%.
Bug: 35768998
Bug: 32312123
Test: Generating the same incremental w/ and w/o the CL give identical
output packages.
Change-Id: Ia5c6314b41da73dd6fe1dbe2ca81bbd89b517cec
This reverts commit a7316ce094.
This CL differs from the original CL by not unzipping RADIO/*. This is
because: a) AOSP targets don't have RADIO/ entries in the TF.zip; b)
we're not using the unzipped RADIO files (but reading them from the zip
files directly) - checked all the device-specific releasetools for
angler, bullhead, ryu, shamu, volantis, fugu, marlin and sailfish.
Test: `m dist` with AOSP targets (tested fugu and bullhead).
Change-Id: I4d0c67214ddd6202fc27c71bb79f52b5f4d40c64
This reverts commit aa3a04f19d.
Reason for revert: Some AOSP targets don't include RADIO/ in the TF.zip. We may possibly skip unzipping RADIO/, or by always creating a dummy RADIO folder in TF.zip. Revert this CL for now.
Change-Id: I8e90d322706a4fe82129bdfab5ffa1eab989c648
When building BBOTAs, it only needs *some* unzipped entries in the given
target_files zip(s). In particular, it needs 'IMAGES/*', 'META/*',
'RADIO/*'. (It also reads 'SYSTEM/build.prop' and 'OTA/bin/updater', but
directly from the zip file.)
This CL specifies the entries to unzip. It saves the I/O cost, as well as
the temporary storage.
Test: ota_from_target_files.py gives the same package w/ and w/o the CL.
Test: check_target_files_signatures.py still works.
Change-Id: I728428aa0e138879e49f9efbdb46a85892fc7038
This remove the fstab dependency when building the OTA package for
marlin/sailfish.
Bug: 35811655
Test: OTA package builds successfully for sailfish.
Change-Id: If223d11dddca396c47262042c576f9e7d0cb5b33
(cherry picked from commit 7d051adc3b)
fstab_version is defined by RECOVERY_FSTAB_VERSION in
bootable/recovery. We have moved to fstab_version 2 since commit
f35d1cef7c19db975a1295e8c23c7fb8bd2489f9 (landed into JB MR2).
Drop the support for fstab_version 1, since we won't run the latest OTA
script over a JB target_files zip.
Test: No impact on building full/incremental OTAs.
Change-Id: Ia87c4e7da6c5e71ce0908fca2e4f1ad1c06ba869
The merged two branches have become identical since commit
fc3422ad36 (landed into Nougat).
Test: Get identical incremental packages w/ and w/o the CL.
Change-Id: Id1183f8ed83f684a0dac1a4af87b6e075b08aabc
We use the timestamps in builds to determine a downgrade, which might
not be always the truth. For examples, two builds cut from different
branches may carry timestamps in a reverse order. An incremental package
won't be able to be pushed nor applied, based on the timestamp
comparison.
We used to handle such a case with manual work, by setting the
post-timestamp to (pre-timestamp + 1) in the package metadata. This CL
automates the process by adding a new flag --override_timestamp.
Note that it doesn't change anything in the installed image, but only
affects the assertions for pushing / installing the package.
With the change in this CL:
- If it's a downgrade without any extra flag, fail the package
generation (we only print warnings prior to this CL);
- If it's a downgrade with --downgrade flag, generate a downgrade
package with forced data wipe (same as before);
- If it's a downgrade with --override_timestamp, generate a normal
incremental with hacked timestamp (pre-timestamp + 1) (new in this CL
to avoid the manual change);
- If it's not a downgrade but with any of the above two flags specified,
fail the package generation.
Bug: 33744169
Test: Generate an incremental from builds with reversed timestamps.
Change-Id: I8b187d32708b4a7c3e20f8c6adb8f9527b73b965
We introduced META/misc_info.txt to hold the misc info since Gingerbread
(commit 37974731fc). Remove the backwards
compatibility support for building pre-G TF zips.
Test: `m dist` works.
Change-Id: Ibff7aaf69cc7e460634c049d11a004f7196f8f73
Otherwise the comparison is inconsistent between ReviseStashSize() and
WriteTransfers().
Bug: 35775675
Test: Successfully generate a previously failed incremental.
Change-Id: I554a51a210bf322cb5c79e28cf85607a417b094a
This CL changes the --oem_settings flag to allow a comma seperated list of
property files. All property values will be used when asserting properties such
as ro.product.name.
For example, if two property files are provided with ro.product.name values of
"sprout" and "sprout_a", the resulting otapackage will check that the device's
ro.product.name property matches at least one of them.
Bug: 34191373
Test: manual
Change-Id: I954673511be8f0929982235cc9cbfbd85a9ee1f4
Commit e98fb7a8d3 switched to using
futility-host instead of the prebuilt futility. This CL adds support to
handle signing old TF.zip that still says "futility=prebuilt/..." in
META/misc_info.txt.
Bug: 35467608
Test: Generate otatools.zip and sign an old ryu TF.zip.
Change-Id: I48a9cc918c7afce361e1ec9bc4f85f74fa92566e
We check the needed stash size in ReviseStashSize(), and may not
generate a stash command if it would exceed the max allowed size. This
CL fixes a bug when skipping a stash operation: we shouldn't update the
'stashes' map if a stash command won't be generated.
Bug: 35313668
Test: Successfully generate the package that was failing due to the bug.
Change-Id: If0a3a5fadda9b4a4edad66a2a5826b5f978400ae
We already support generating downgrade OTAs for non-A/B devices (with
mandatory data wipe), but we have missed the --downgrade flag in A/B OTA
path.
This CL factors out the function that writes the downgrade metadata, and
fixes the path for generating A/B OTAs.
Bug: 35094540
Test: Generate incrementals with --downgrade for A/B and non-A/B OTAs.
Change-Id: I30b9bf83e69e8aba3be666507681b555db6ab743
Commit f1a13180db intended to remove the
verity blocks from care_map.txt, but it added new code without removing
the old one. This leads to a malformed care_map.txt and causes
update_verifier failure.
Bug: 34391662
Test: 'm -j dist' gives a TF.zip with 4-line META/care_map.txt (as
opposed to a 6-line file).
Change-Id: I7ff1aa525795c4b049af54c1755b0f0ea84f7e0e
For streaming OTAs, we will also need the info in the metadata entry
(META-INF/com/android/metadata). Compute and pack its offset/length
values into 'ota-streaming-property-files'.
Bug: 34986195
Test: Create an OTA package and check the offset/length values.
Change-Id: Id150700f2bc9bff02467cda9fe8927c8a374412a
'streaming-property-files' is a property related to the OTA package
itself. Prepend 'ota-' to make it consistent with others like
'ota-type' and 'ota-required-cache'.
Bug: 34852392
Test: Generate an A/B OTA package and check METADATA entry.
Change-Id: Ia681e6e19ff509e6da0d8718933b42aac997e1cf
When reading /dev/block/dm-X, update_verifier isn't able to access the
verity meta blocks at the end of the system/vendor partition. So we need
to remove these block ranges from the care_map.
Bug: 34391662
Test: care_map generated successfully without verity meta blocks
Change-Id: Id57c602b7e5fd1b0c9d1e1fe5fcdd74e85b6b255
This reverts commit ea4325baf8 to re-land
commit ef1bb4360f. It fixes the bug when
handling a package without care_map.txt (e.g. dm-verity not enabled).
In order to support streaming A/B OTA packages, we pack
payload_properties.txt and care_map.txt in ZIP_STORED mode. These two
entries along with payload.bin (already in ZIP_STORED prior to this CL)
can be fetched directly based on the offset and length info.
We write the offset and length info into the package metadata entry
(META-INF/com/android/metadata), which can be parsed by the OTA server.
payload_properties.txt and care_map.txt are usually less than 1-KiB. So
the change only incurs marginal size increase.
Bug: 33382114
Test: Generate an A/B OTA package. Verify the 'streaming-property-files'
entry in the metadata file.
Test: Generate an A/B OTA package on a device with dm-verity not enabled.
Change-Id: I3469c8b62385a1fc58b4fb82e3f9d4690aef52ba
In order to support streaming A/B OTA packages, we pack
payload_properties.txt and care_map.txt in ZIP_STORED mode. These two
entries along with payload.bin (already in ZIP_STORED prior to this CL)
can be fetched directly based on the offset and length info.
We write the offset and length info into the package metadata entry
(META-INF/com/android/metadata), which can be parsed by the OTA server.
payload_properties.txt and care_map.txt are usually less than 1-KiB. So
the change only incurs marginal size increase.
Bug: 33382114
Test: Generate an A/B OTA package. Verify the 'streaming-property-files'
entry in the metadata file.
Change-Id: I04504e834eb36e18876c5f5a5a09289ee05c6f9a
It was added in commit 96be7205dc
("Working ASLR implementation.") in 2010, and removed in commit
1807e700a5 ("don't generate retouch
commands in OTA scripts") in 2012.
Remove the obsolete --aslr_mode flag.
Test: ota_from_target_files.py still works (by generating incremental
and full OTAs respectively).
Change-Id: I6d8e62730ac192f3574d484c4a4b9b43b4ee0a9e
This information can be used to tune ext4 stripe and stride in the
userdata partition for better performance
Test: Build & flash userdata, confirm correct stripe & stride values
Bug: 33243520
Merged-In: Ia97cdd2d0239c3484b895fce49299f692ef911d8
Change-Id: Ia97cdd2d0239c3484b895fce49299f692ef911d8
Signed-off-by: Connor O'Brien <connoro@google.com>
Only BBOTA v2 needs to maintain a pool of available 'stash slot id'.
BBOTA v3+ uses the hash of the stashed blocks as the slot id, which
doesn't need the id pool anymore.
Bug: 33694544
Test: Generate v2 and v4 incrementals w/ and w/o the CL. They produce
the same packages respectively.
Change-Id: I8121af5b6b1bee98c3639d54a00b06fd12e378e8
We compute the max stashed_blocks in ReviseStashSize(), prior to calling
WriteTransfers(), to avoid running out of space due to stashing.
There is a bug when computing the to-be-freed stashed blocks, where we
wrongly free the space _before_ executing the transfer command. This leads
to a script failure where the max stash size violates the max allowed
size in WriteTransfers().
Note that this bug doesn't affect already generated packages. It's only
an underestimate in ReviseStashSize(). The check in WriteTransfers() has
been correct to ensure the max stash size.
Bug: 33687949
Test: Successfully generated incremental OTA which failed previously.
Change-Id: I4f4f043c6f521fce81ca5286e6156f22d99bf7f7
We used to dump "Source: <fingerprint>" in update logs. The "Source: "
prefix was unintentionally dropped out.
Test: Check the generated incremental BBOTA script.
Change-Id: I4de62333aa38e3fb09a76df0e769b62af48e0313
Add support for specifying number of inodes when creating
system, vendor, oem partitions. These are all read-only
and have no use for extra inodes. Removing extra inodes
saves a lot of space.
Bug: 32246383
Change-Id: I13f1d4614b64a4abc752c42a1c65d3d151481c21
(cherry picked from commit b59eca3586)
In two-step OTAs, we write recovery image to /boot as the first step so
that we can reboot from there and install a new recovery image to
/recovery. However, bootloader will show "Your device is corrupt"
message when booting /boot with the recovery image. Because the recovery
image encodes the path of "/recovery" as part of the signature metadata,
which fails the verified boot.
This CL generates a special "recovery-two-step.img" in addition to the
regular recovery.img. This image encodes "/boot" when being signed,
which will be flashed to /boot at stage 1/3 in a two-step OTA.
Here are the desired changes:
- 'IMAGES/recovery-two-step.img' exists in target_files.zip for non-A/B
targets (e.g. bullhead). The image should not exist for targets that
don't have a recovery partition (e.g. A/B devices like sailfish).
- <device>-img.zip should not contain 'recovery-two-step.img'.
- Nothing should change when building non-two-step OTAs. For two-step
OTAs, 'recovery-two-step.img' should be included in the OTA package;
'updater-script' should flash this image to /boot at stage 1/3.
- When building a two-step OTA with an input TF.zip that doesn't have
IMAGES/recovery-two-step.img, it should use the existing
IMAGES/recovery.img instead.
Bug: 32986477
Test: Tested the steps above on bullhead and sailfish.
Change-Id: I34e6c599bcf2011d4cd5c926999418b3975d6d0f
The 'system_img_path' parameter was introduced in commit
d995f4b04d, but became obsolete since
commit 2ce63edab7.
Test: m dist
Change-Id: Iffd496d929db5cc3dfc955a48bfc1b1317bd012f
We are investigating replacing make_ext4fs with the upstream tool mke2fs.
To mitigate the trouble that may arise if the new tool behave differently
compared to the old one, there will be a transition period.
Devices that want to use the new way of creating ext4 images can set the
variable "TARGET_USES_MKE2FS" to true in their BoardConfig.mk
By default, the build system will choose the old tool 'make_ext4fs'.
Test: m otapackage with TARGET_USES_MKE2FS={,false,true}
Change-Id: I282bcb9efe335a86c53986283090ca947d65c7f8
Prior to this CL, it was calling the hard-coded "java" although it was
accepting a "--java_path" option.
Also switch OPTIONS.java_args from string to list. Otherwise it won't
work when providing multiple args.
Bug: 32737832
Test: Specify "--java_path=" and "--java_args" when invoking
sign_target_files_apks.py with "-v". Check the commands being
called.
Change-Id: Id7ef98e778646d532027434de7fba9b7a104dbd0
set() doesn't keep elements according to the order of insertion. So
Transfers managed with set() in intermediate steps may not appear in the
same order across runs. This leads to slightly different output packages
when generating the same incremental OTA.
This CL fixes the issue by replacing set() with OrderedDict() in
blockimgdiff.GenerateDigraph() and blockimgdiff.FindVertexSequence().
It also adds a testcase that ensures blockimgdiff.GenerateDigraph()
preserves the insertion order for Transfer.goes_after set.
Bug: 32220816
Test: ota_from_target_files.py gives identical package when running
multiple times.
Change-Id: I56d551e5ca926993ab46896e33c80e0ce42e506a
Currently, whether contains patch or verbatim, compute with file size
and patch size.
But ota file must be compressed with zip, so it should be better with
compressed size than uncompressed.
Test: aosp_shamu-user build without proprietary blobs between MOB30P and NRD90S
$ du -k ota_shamu_old.zip ota_shamu_new.zip
217252 ota_shamu_old.zip
216520 ota_shamu_new.zip
Change-Id: If68cb1fbe2f7815067451915a0dcfe93ea5ba8d6
Signed-off-by: YOUNG HO CHA <ganadist@gmail.com>
system/extras/verity/build_verity_metadata.py now accepts
"--signer_args" to specify verity signer args.
Also remove the duplicate "--verity_signer_args" in
add_img_to_target_files.py, as we already have that in common.py.
Bug: 31500665
Test: Building and signing work w/ and w/o --signer_args.
Change-Id: I02f59c50a1ebf15c5505e9fffd5b9bbbbaa785be
While the system.img images currently built with AVB support verify
correctly, mounting the filesystem content fails. This is because
'avbtool add_hashtree_footer' used to claim some of the unused /
DONT_CARE space for stashing the verity tables and this resulting in the
mapped device ending up being smaller causing the mount failure.
Fix this by leaving enough room for AVB hashtree and metadata before
building the image. This is achieved by moving the AVB hashtree support
into build_image.py and using a just added '--calc_max_image_size'
option to 'avbtool add_hashtree_footer' to figure out how much space to
leave out.
This depends on https://android-review.googlesource.com/#/c/281821/
Bug: 31264226
Test: Mounting dm-verity set up from system.img now works.
Merged-In: I4c5de1004c1059f8c582e76b3b8517d427aa1a87
Change-Id: I945a5f1f6782791736cd319f216cfa6b448fb04d
Remove the obsolete workaround for API 24. Also make it pylint clean.
Test: 1. Sign a target_files.zip and get identical results.
2. `pylint --rcfile=pylintrc sign_target_files_apks.py` gives 10.00/10.
Change-Id: I21736f959c5182486fd8ccebea9bbc594edef9fb
sign_target_files_apks.py calls common.GetBootableImage() but without
calling 'OPTIONS = common.OPTIONS' first. In common.GetBootableImage(),
we should use the local info_dict parameter instead of OPTIONS.info_dict.
Test: sign_target_files_apks.py generates signed-TF.zip successfully.
Change-Id: Ia3d32b88691c26e5fb98feea709e3e3c3eb70fdb
This updates the build system for the new Android Verified Boot
codebase. As this is based on Brillo Verified Boot, this change replaces
the existing BVB support.
Android Verified Boot is enabled by the BOARD_AVB_ENABLE variable
BOARD_AVB_ENABLE := true
This will make the build system create vbmeta.img which will contain a
hash descriptor for boot.img, a hashtree descriptor for system.img, a
kernel-cmdline descriptor for setting up dm-verity for system.img and
append a hash-tree to system.img.
Additionally, the descriptors are left in boot.img and system.img so a
third party can create their own vbmeta.img file linking - using the
option --chain_partition - to these images. If this is not needed
footers can be erased using the 'avbtool erase_footer' command. It's
also harmless to just leave them in the images.
By default, the algorithm SHA256_RSA4096 is used with a test key from
the AVB source directory. This can be overriden by the
BOARD_AVB_ALGORITHM and BOARD_AVB_KEY_PATH variables to use e.g. a
4096-bit RSA key and SHA-512:
BOARD_AVB_ALGORITHM := SHA512_RSA4096
BOARD_AVB_KEY_PATH := /path/to/rsa_key_4096bits.pem
To prevent rollback attacks, the rollback index should be increased on a
regular basis. The rollback index can be set with the
BOARD_AVB_ROLLBACK_INDEX variable:
BOARD_AVB_ROLLBACK_INDEX := 5
If this is not set, the rollback index defaults to 0.
The variable BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS can be used to specify
additional options passed to 'avbtool make_vbmeta_image'. Typical
options to be used here include '--prop', '--prop_from_file', and
'--chain_partition'.
The variable BOARD_AVBTOOL_BOOT_ADD_HASH_FOOTER_ARGS can be used to
specify additional options passed to 'avbtool add_hash_footer' for
boot.img. Typical options to be used here include '--hash_algorithm' and
'--salt'.
The variable BOARD_AVBTOOL_SYSTEM_ADD_HASHTREE_FOOTER_ARGS can be used
to specify additional options passed to 'avbtool add_hashtree_footer'
for systems.img. Typical options to be used here include
'--hash_algorithm', '--salt', and '--block_size'.
BUG=31264226
TEST=Manually tested on edison-eng by inspecting {boot, system,
vbmeta}.img in out/ directory as well as their counterparts in
the IMAGES/ directory of edision-target_files-eng.zeuthen.zip
Merged-In: Ic9a61cfc65c148b12996e57f04da5432eef6b982
Change-Id: I97042655bca15e7eac899f12c5bada2f6184d307
In BBOTA, we generate patches based on _all_ the blocks of a pair of
input files (src and tgt). For security incremental OTAs, one common
pattern is that only a few blocks are changed in odex files (e.g.
headers). We don't really need to stash/patch the unchanged blocks.
This CL analyzes the unchanged blocks in odex files and computes the
diff for the changed blocks only. It reduces the OTA install time by
about 25% to 40% in our experiments, by paying an increase of 5% to 30%
OTA generation time cost.
Bug: 31570716
Test: Generate an incremental and apply on device.
Change-Id: If842c1afeff6894a3d27eb60b7e8f65a179b7977
tempfile.TemporaryFile() complains when 'None' is passed as the
prefix/suffix. It uses prefix='tmp' and suffix='' as the default values
and we should do the same.
Test: Call check_ota_package_signature.py and ota_from_target_files.py
and they still work.
Change-Id: I7fb023a3fd0b1a57c009631d0c57a7bb8e4cb5a3
Currently it supports verifying packages signed with RSA algorithms
(v1-v4 as in bootable/recovery/verifier.cpp). No support for ECDSA (v5)
signed packages yet.
$ ./build/tools/releasetools/check_ota_package_signature.py \
bootable/recovery/tests/testdata/testkey_v1.x509.pem \
bootable/recovery/tests/testdata/otasigned_v1.zip
Package: bootable/recovery/tests/testdata/otasigned_v1.zip
Certificate: bootable/recovery/tests/testdata/testkey_v1.x509.pem
Comment length: 1738
Signed data length: 2269
Use SHA-256: False
Digest: 115e688ec3b77743070b743453e2fc6ce8754484
VERIFIED
Bug: 31523193
Test: Used the tool to verify existing packages (like above).
Change-Id: I71d3569e858c729cb64825c5c7688ededc397aa8
For some partition sizes, we currently build an image that's 1-2
blocks smaller than the actual partition, which causes fs_mgr to
not find metadata. This change adds padding to FEC metadata that
correctly positions the metadata header at the end.
Bug: 28865197
Change-Id: Ie0e044715a9c5ae8ba395e7d2ff9fbd7cffc0b4c
The userdata.img and cache.img entries are not useful in signed builds;
because fastboot doesn't look at these two entries in the *img.zip when
flashing a device. And they aren't used elsewhere. Therefore, skip
building the image files for them when signing the target files with
sign_target_files_apks. Also, add an option "--is_signing" to avoid
adding these two images when we call add_img_to_target_files.
Change-Id: I39ba91a86d9a856d7d01771f6d1403dbf21f2011
Test: Run sign_target_files_apks on a target file and userdata/cache.img doesn't not generate.
Bug: 30642470
add_img_to_target_files.py fails when the target_files.zip is over 4GiB
when adding IMAGES/ folder. Specify the flag to allow creating
target_files.zip with ZIP64 extension.
Other zip artifacts (-img.zip, -ota.zip etc) remain in non-ZIP64 format.
zip2zip is not affected, which still creates non-ZIP64 zips even when
copying from target_files in ZIP64.
Bug: 30961841
Test: "make dist" with large system image and check the artifacts.
Change-Id: I0568745f01ef8f0239081f783eac92288d4fdd84
Do not copy the "META/care_map.txt" from the source zipfile when
signing the target files with sign_target_files_apks. Because we'll
generate a new care_map after rebuilding the system/vendor images;
and we'll write the new "META/care_map.txt" to the signed-target-file.
Change-Id: I6919cfdf8314a4084b5f612a9c89469f391486a4
Test: Run sign_target_files_apks locally, and the entry is updated.
Bug: 30812253
On A/B devices (i.e. system_root_image="true"), /default.prop is
packaged at ROOT/default.prop (as opposed to BOOT/RAMDISK/default.prop
for non-A/B devices). Update the path so that we handle properties like
ro.bootimage.build.fingerprint properly.
The one for recovery is not affected, which stays at
BOOT/RAMDISK/default.prop for A/B devices and gets updated correctly.
Bug: 30811237
Test: Verify the property in the generated signed-TF.zip.
Change-Id: Id201a042d7ea988a64f89c6d04f43326a9851e27
The update-payload-key is used by update_engine_sideload from recovery
to verify an update payload.
Bug: 27178350
Change-Id: I7a0a307ae565e5e9cbf2c9b58fbcc055e87771ce
We were using the package name as the key to index APKs. APKs from the
same package got messed up and gave wrong signature summary. Switch to
using the package filename as the key, which is identical in a given build.
Also fix the trailing space when printing the signature summary.
Bug: 30418268
Test: Run with a target_files.zip that has multiple APKs from the same package.
Change-Id: I6317e8c05e987c5690915e05c294153d10e2f0ab
We should disable using imgdiff if *any* of the source and target
partitions uses squashfs.
Bug: 30004734
Test: Create an incremental with two builds with one of them uses squashfs.
Change-Id: I826cd13d7b852c548e4b45e61f5ae00f6407cac3
(cherry picked from commit f8acad1480)
We use imgdiff to handle files in zip format (e.g. jar/zip/apk) for
higher compression ratio.
For system/vendor in squashfs, a) all files are compressed in LZ4
format; b) we use 4096-byte block size in their sparse images, but the
files in squashfs may not be laid out as 4K-aligned. So the blocks for
a given file as listed in block map may not form a valid zip file, which
may fail the patch generation with imgdiff.
Disable using imgdiff for squashfs images, and use bsdiff instead.
Bug: 22322817
Change-Id: Ie76aa4cece5c9d38cb1d1a34c505a4a8f37512d3
(cherry picked from commit 293fd135c7)
Generate a new file containing care_data of system (and vendor)
partition, and add it under META/ of target file package. For
A/B update, copy this file to OTA package for later use by
update_verifier.
Bug: 27175949
Change-Id: I90bb972703afaeb94bc3efe718fd81b1cfbcabcc
update_engine expects the extracted public key instead of the
certificate.
Bug: 28701652
Change-Id: I292d39da9e039f96d01a4214226aeb46f8cb881d
(cherry picked from commit afaf295cb8)
We should disable using imgdiff if *any* of the source and target
partitions uses squashfs.
Bug: 30004734
Test: Create an incremental with two builds with one of them uses squashfs.
Change-Id: I826cd13d7b852c548e4b45e61f5ae00f6407cac3
add_img_to_target_files.py has an option of "-a" to add missing
images only. Under this option, the script should skip copying
the radio images for A/B devices when given image exists already
under "IMAGES/".
Test: Run the command on an A/B device, the existing radio images under "IMAGES/" don't get overwritten; and missing images are added correctly.
Bug: 29608905
Change-Id: Ie034b85a5d777d53e367f99470cea4d19cb1aaaf
For AB devices, support flashing two system partitions for factory use.
The normal system image on one partition, but without dex preopt. And a
system_other image that just contains the odex files. The dex files will
not be stripped out of the system image, in case the second system
partition is wiped.
Setting BOARD_USES_SYSTEM_OTHER_ODEX := true in the BoardConfig.mk
enables this behavior.
One can control which directories are placed in system_other by the
SYSTEM_OTHER_ODEX_FILTER configuration variable. Currently we default
to only copying only app and priv-app odexs.
Bug: 29278988
Change-Id: I7f4e87da919e7dc6a89fd8c668193cd4e98631bc
system_root_image expects the key at ROOT/verity_key as opposed to
BOOT/verity_key. Also refactor the verity key replacement lines.
Bug: 29397395
Test: 'sign_target_files_apks.py --replace_verity_private_key newkey --replace_verity_public_key newkey.pub target_files.zip signed-target_files.zip' and verify the replaced key in boot.img.
Change-Id: I58a5defff4be008ad55d4b5a5b7148569c3b8d66
(cherry picked from commit e0ee794fa1)
For A/B OTAs, by default it calls 'openssl pkeyutl' to sign the payload
and metadata with the package private key. If the private key cannot be
accessed directly, a payload signer that knows how to do that should be
supplied via "--payload_signer <signer>".
The signer will be called with "-inkey <path_to_private_key>",
"-in <input_file>" and "-out <output_file>" parameters.
Test: Use a dummy signer, call 'ota_from_target_files.py --payload_signer <signer> <target_files.zip> <ota.zip>' and verify the signatures in the generated package.
Bug: 28701652
Change-Id: I26cfdd3fdba6fc90799221741b75426988e46fd3
(cherry picked from commit dea0f8bfed)
Replace verity keyid with the keyid extracted from cert
passed through --replace_verity_keyid. The veritykeyid in the
BOOT/cmdline of input target files is replaced with keyid
extracted from --replace_verity_keyid and written to the
output target files.
BUG: 28384658
Change-Id: Ic683f36f543c4fcd94b6f95e40f01200fbf45ee1
(cherry picked from commit b58d23fe00)
It replaces the package verification key (change of path due to
system_root_image flag), as well as the payload verification key.
Bug: 29397395
Change-Id: I10435072aaf4356f2d8b5e1b6e82eb9cead7ad62
(cherry picked from commit 24a7206430)
Limit the number of blocks in each 'new' command to 1024. This should
decrease the chance of fsync error during an OTA update, similiar to
what we have done in b/29535618.
Bug: 29607757
Change-Id: I89f0a845d71eb810766e39860ab667c61b61a417
system_root_image expects the key at ROOT/verity_key as opposed to
BOOT/verity_key. Also refactor the verity key replacement lines.
Bug: 29397395
Test: 'sign_target_files_apks.py --replace_verity_private_key newkey --replace_verity_public_key newkey.pub target_files.zip signed-target_files.zip' and verify the replaced key in boot.img.
Change-Id: I58a5defff4be008ad55d4b5a5b7148569c3b8d66
