python3.11's zipfile implementation does not handle symlinks. This
causes important symlinks in ramdisk to be broken, and later causing a
boo failure.
Test: unzip a target files with symlinks, make sure symlinks are created
Bug: 287896098
Change-Id: Ia7d6ac8ffb03807680a36ff648aa11afafb7f481
Partition images are allowed to be in either IMAGES/ or RADIO/ dir of a
target_files zip, so when searching for .map files we should look in
both dirs.
Test: th
Bug: 227848550
Change-Id: I0a9d2c582d8f5d570237434902fac012513c9aad
Supply generator with parameter --apex_info_file=META/apex_info.pb
if the file exists.
This ensures that apex_info is included in payload header.
This is identical to the behaviour of brillo_update_payload
which is not being used since:
Invoke delta_generator directly
fcd731e3d6
Issue: 286253576
Test: Manual, confirm that apex_info is included in payload header
Change-Id: Ic096c5f8966beec8686f918aba462c955290a6c5
The following log message would always be shown:
WARNING : Cannot find care map file in target_file package
Break out of the care map copying loop as soon a file has been
copied. This ensures that else statement is only executed if no
care map file exists.
Test: Manual. Run ota_from_target_files with target-zip with and
without care map files.
Change-Id: Ia196aa182ed81f21424317a7005f5634866b4b99
When building images via `m` , build_image.py is invoked directly
without going through add_img_to_target_files. To ensure images built in
either way are identical, move uuid/salt computation to build_image.py,
so that the same uuid/salt will be used.
Bug: 281960439
Test: m installclean && m && m target-files-dir , maks sure images in
$OUT and $OUT/obj/PACKING/target_files_intermediates are identical
Change-Id: Icdab29df84f5a0ec7c080f99f9fdbdc3c9b10b90
Fastboot_info can be disabled if use_fastboot_info is set to false.
Adding this flag as fastboot-info.txt is currently broken
Test: m updatepackage -> inspect contents
Bug: 284263071
Change-Id: I3e0ca13968ba9747cc39284ea6798981d22ad5e5
We don't actually need write permission, so going with least privilege
principle. We have observed some mysterious permission denied errors on server environments. Without detailed logs or access to the server it's hard to pinpoint what the root cause is. This is an attempt/hypothesis to fix the permission denied error.
Test: th
Bug: 283033491
Change-Id: I52dc360d593aab57c749109994bf3e1e3625d0ce
Add options to handle custom payload signer as it is required in
merge_ota.py as well if the original OTA packages are signed by
the signer.
If input is only one OTA, clone apex_info.pb to the target.
Use common.ZipWriteStr instead of zipfile.writestr, this ensures
that the same permission for the entries as done by
ota_from_target_files.
Bug: 282189563
Test: manual. pass single OTA to merge_ota, with same signing
parameters as originally used. Confirm that output zip is
binary identical to input.
Change-Id: I3b926b8cd69bc74dff6ccf8b5ccc72bedffcac6f
common.LoadInfoDict() already supports loading from extracted
directories, just use it.
Test: generate an incremental OTA where both inputs are directories
Bug: 227848550
Bug: 277028723
Change-Id: Iedba831bb4d65d971df6b2ac95279e3234a02e2f
if output_zip isn't None, writing into zip file in parallel is not
thread-safe.
Bug: 281960217
Test: m dist
Change-Id: I10d68a4bb779cee244f40410ec95d38ca6040306
it made total time equal to the longest image build
1m10s->30s in local build
Bug: 281960217
Test: m dist
Change-Id: I13d4f45d9b46b39292a014e3b4e1913365d89b7a
Modifying img_from_target_files to also add fastboot-info to
updatepackage
Test: m updatepackage
Bug: 194686221
Change-Id: I2e08c4269f0d83417b9d7079633bc28796d1cdd6
This allows the build system to potentially paralleize generation of OTA
package and zipping of target files
Bug: 262185376
Bug: 227848550
Change-Id: I90b6c25761683ebe3803b22fc8e23540a5282c66
