In the past, we have been generating brick OTA packages manually.
Automate this process.
Bug: 273561331
Test: create_brick_ota --product oriole brick.zip and apply the package
Change-Id: I7f4cf3cacaedd9d376b4cc07cbb388930bca643b
Add test cases to cover HAL definition found in embedded APEX.
Bug: 249086047
Test: releasetools_test
Change-Id: I5639b9b800a89164317740f64306ae10bf41343e
Flattened apexes are extracted and copytree()'d to /apex directory to
simulate "activation" on device.
Bug: 242314000
Bug: 239055765
Test: m otapackage # target with "flattened" apexe
Change-Id: I90cc37b5f64ebad1e15f6fc5fa245d0f5955095d
Change-Id: I7e8c3fdf8e4620344d23cee0de509e574206ad9b
Care maps need to store the original image size, which excludes bytes
used by hash tree or FEC code.
We used to propagate original image size using the global OPTIONS
dictionary. This is bad coding practice, and also fragile because we
have to make sure what's stored in dictionary and what's on disk are
consistent. Instead, let's read the content of images on disk, and parse
the AVB footer. The AVB footer contains the ground truth original image
size.
Test: build OTA, make sure the care maps have valid range
Bug: 246504616
Change-Id: I9250b478ab34dda60578a6b8c23ae6d7a9385788
As part of extending libvintf to support VINTF data inside of APEXes:
Create apex-info-list.xml as part of build to pass into checkvintf.
Include the /apex data to dirmap
Extend check_target_files_vintf.py to include APEX data:
Unzip APEX from partions
Extract APEX data
Create apex-info-list.xml
Bug: 239055387
Bug: 242314000
Test: m
Test: m dist
Change-Id: I4b4e159051bacb46dc43b83e006ca0f0eb58d772
Some partners have large number of products that share common
images. Generating OTAs for all these products waste a lot of CPU
cycles, because we waste time diffing the same images multiple times.
To mitigate this, add a tool for merging partial OTAs. Partners can
generate a partial OTA for common images, and re-use the generated OTA
by merging with each product specific OTA.
Bug: 227848550
Test: Run merge_otas.py on 4 OTAs, install the generated OTA
Change-Id: Ie38d522cdc9b89b1123b3d8190516c3648f99788
This makes it easier for other otatools to re-use these logic without
having to pull in lots of dependencies.
Test: th
Bug: 227848550
Change-Id: I81ed01c5cea4b934a074650731b6f89752221de9
Let the fsverity_manifest_generator logic be reused and just keep the
bits to generate the BuildManifest.apk. Since this can all be acheived
with a series of shell commands, remove the python script and just do it
directly in the Makefile.
Bug: 237384936
Test: TH
Change-Id: I168dc1cea0be72b5098f99e4183e080a687fb03e
This will be used in the following change to split
merge_target_files into a collection of smaller
more-focused scripts.
Bug: 221858722
Test: m otatools; Use to create merged builds
Change-Id: Ie01dac81c5f9f28f1e0fe037259eabd2478e60b6
These wrapper scripts are difficult to maintain and there's not really
any value add. The argument strings don't match and every new build flag
has to be connected in an extra place.
Bug: 222715577
Test: make with EROFS enabled
Change-Id: Ie0e51cc30aa08b004d5d8345a2a2d885e193ffa9
build_image.py has been handling fsverity metadata generation in the
packing step, but it can cause issues because the metadata files are
missing in the $OUT directory, and they only exist in result system.img.
This change moves the generation logic into Makefile, and makes the
metadata tracked by ninja graph.
Bug: 206326351
Test: PRODUCT_SYSTEM_FSVERITY_GENERATE_METADATA := true and build
Change-Id: I1f910d8ac6e2cc3c54f35916871733c632f18e44
Making this a host tool will help users generate their own fsverity
metadata easily.
Bug: 205987437
Test: m fsverity_metadata_generator and run it
Change-Id: Iafd228815a74d298d87ca1466c6909c0d24c5874
fsverity digest manifest stores a map from files to fsverity digests.
The manifest is installed as a serialized protobuf file, to a signed apk
system/etc/security/fsverity/BuildManifest.apk.
Bug: 193113311
Test: build with PRODUCT_SYSTEM_FSVERITY_GENERATE_METADATA := true
Change-Id: I55fc10400206b8ce0d5f198faea08fe3930b362c
Using fsverity tool, fsverity metadata for specific artifacts in system
mage can be generated. Users can do that by setting a makefile variable
PRODUCT_SYSTEM_FSVERITY_GENERATE_METADATA to true.
If set to true, the following artifacts will be signed.
- system/framework/*.jar
- system/framework/oat/<arch>/*.{oat,vdex,art}
- system/etc/boot-image.prof
- system/etc/dirty-image-objects
One fsverity metadata container file per one input file will be
generated in system.img, with a suffix ".fsv_meta". e.g. a container
file for "system/framework/foo.jar" will be
"system/framework/foo.jar.fsv_meta".
Bug: 193113311
Test: build with PRODUCT_SYSTEM_FSVERITY_GENERATE_METADATA := true
Change-Id: Ib70d591a72d23286b5debcb05fbad799dfd79b94
The release tools have already been updated in prior cls to
support python 3. To test this, I added code to print the script
name to a temp file at the beginning of every script, and then
ran various builds, ensuring that the scripts were run afterwards.
The builds run:
m brillo_update_payload checkvintf minigzip lz4 toybox unpack_bootimg deapexer (needed for releasetools_test)
m (as both sdk_phone_x86_64 and beagle_x15)
m target-files-package (as both sdk_phone_x86_64 and beagle_x15)
m releasetools_test && out/host/linux-x86/nativetest64/releasetools_test/releasetools_test (25 errors with and without python3)
m check_target_files_signatures apksigner target-files-package && out/host/linux-x86/bin/check_target_files_signatures out/target/product/emulator_x86_64/obj/PACKAGING/target_files_intermediates/sdk_phone_x86_64-target_files-eng.colefaust.zip
m dist
As aosp_cf_x86_64_phone: m dist && sign_target_files_apks out/dist/aosp_cf_x86_64_phone-target_files-eng.$USER.zip /tmp/signed_target_files.zip && validate_target_files /tmp/signed_target_files.zip
This hit all the scripts except for make_recovery_patch,
merge_builds, and ota_package_parser.
I couldn't find anything that uses merge_builds, so it must
only be run manually.
make_recovery_patch and ota_package_parser are only run if
TARGET_OTA_ALLOW_NON_AB is true (among other things), which
is not the case for any product in aosp.
Test: Described in commit message + presubmits
Change-Id: I1a29eafa7ff1a69973b27055e311de77f7ee628b
When generating a partial OTA, filter care_map.pb to include only the
partial partitions, then generate OTA.
Test: Generate a partial OTA, make sure care map is included.
Change-Id: I0eaa12772eb1d06a57451e64f70689d3183f0115
This change intends to fix if ramdisk is not "lz4" compression.
Legacy is "minigzip" compression.
If not lz4, the following error will happen when exec build_super_image.py:
Unable to get boot image build props: Failed to run command '['lz4', '-d', '/tmp/boot_omdZZ8.img/ramdisk', '/tmp/boot_omdZZ8.img/uncompressed_ramdisk']' (exit code 44):
Error 44 : Unrecognized header : file cannot be decoded
Change-Id: I71248387bbeecbf184e0c24e6346c235d728518e
Signed-off-by: jiajia tang <tangjiajia@xiaomi.com>
verity_utils.py gets an entry point and becomes a host binary. This is
to support signing images from the "bootimg" module type. Previously
this was done by directly invoking "avbtool" from the soong module, but
that required people to know the partition_size priori. The partition
size may not be known before actually building the partition image
especially when the partition is not for a physical partition but for a
partition in a composite image.
verity_utils.py, when the partition_size is not given, is capable of
calculating the mininum required partition size based on the size of the
unsigned input image file.
Bug: 180676957
Test: m microdroid_boot-5.10
Change-Id: I7bef292fb141c90899b7bdc0748895f95f964829
This follows the same steps as OpenSplitPolicy() in
system/core/init/selinux.cpp on the device.
Bug: 178864050
Test: merge_target_files for R+S and S+S devices
Test: test_merge_target_files
Change-Id: Ia41a436bfda8e2cb65706122f0ff3805b99d16e1
If an OTA contains compressed APEX inside it, then the device will need
to allocate space on /data partition for their decompression. In order
to calculate how much space the OTA process needs to allocate, the
process needs more information about the APEX contained inside the OTA.
In this CL, we are adding functionality to the OTA generation script
that allows us to gather information about the APEX stored inside the
target-file zip. However, we did not integrate the new functionality
with the ota_from_target_files.py scrip yet. That will be done on follow
up CL.
Bug: 172911822
Test: atest releasetools_py3_test
Change-Id: I2ac42018f628c2c21527b3e086be1f4e7e7247ad
When GetBootImageBuildProp is moved to common, its dependencies
(toybox, lz4 and unpack_bootimg) aren't moved accordingly.
Copy the dependencies over.
Test: pass
Change-Id: Iaa8f41ae0109e8eb1c058ecd7dd854bb7de9391a
All unit_tests:true are run in presubmit which avoids
the explicit definition of TEST_MAPPING.
Test: presubmit runs all those tests
Bug: 175408655
Change-Id: Ibfad3fe2dd8d2fa1ebc6f6bcbd8ab34c2a0069dc
This verifies the init rc files in the merged result.
Bug: 163089173
Test: test_common.py
Test: Run merge_target_files.py to merge two target-files packages where
one has init_rc errors. Observe script failure.
Test: Run merge_target_files.py on two good target-files packages,
observe no failure.
Change-Id: I86c8e5a2bc07c2c1896ac40afd32bc1d055447ee
This involved moving the find-shareduid-violation.py script to
releasetools to simplify the cross-tool usage. This new location aligns
this script with other similar python host tools.
In a future change this violation file will be used to check for
shared UID violations across the input build partition boundary.
Bug: 171431774
Test: test_merge_target_files
Test: Use merge_target_files.py to merge two partial builds,
observe shared UID violations file contents in the result.
Test: m dist out/dist/shareduid_violation_modules.json
(Checking that existing behavior in core/tasks is presereved)
Change-Id: I7deecbe019379c71bfdbedce56edac55e7b27b41
Background in http://go/android-partial-updates. For partial update
(e.g. system-only) or devices with mixed build, the current
fingerprint & device name no longer suffice as the precondition to
install the package.
Therefore, we need to additionally include the per-partition build
props into the ota metadata. We also define a protobuf for the metadata
so it can be extended later. The metadata of the legacy format is also
kept for backward compatibility.
Bug: 151088567
Test: unittest pass, generate an OTA and check the result
Change-Id: I716f7da54a393cd340280dbddc3c92b3460f8ef8
