This commit adds a new `--zip-mode` parameter to `avbroot ota patch` to control whether the patched OTA zip is written with data descriptors or not. By default, the `streaming` mode is used, which matches the current behavior where the zip is hashed for signing as it is being written. The new `seekable` mode fully writes the zip before rereading it to hash the contents. The new mode is useful for devices with broken zip parsers that fail to properly handle data descriptors. All of the end-to-end tests have been duplicated to test both modes. Adding the seekable mode necessitated a couple other changes: * BufWriter is no longer used. Type erasure is very painful in Rust, so we need to keep the writer types the same for both the streaming and seekable modes. BufWriter is unusable in the seekable mode because we need to be able to read back what was written, which isn't supported. * HolePunchingWriter has been removed. It was a simple way to produce sparse files by seeking whenever a write buffer consists fully of zeros. When combined with BufWriter, there was previously never a situation where this was undesirable. However, with the new seekable mode and the zip library's pattern of writing one field at a time, the final 2 zero bytes (representing an empty archive comment) is never written and the file size is not increased either. Removing this is not a big deal since we no longer use stripped OTAs for the end-to-end tests. Those were really the only OTAs that benefitted from sparse files. A real OTA has very few zero bytes due to compression. Issue: #328 Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
End-to-end tests
avbroot's output file is reproducible for a given input file. e2e.toml lists some profiles for generating mock OTA images with unique properties and the expected checksums before and after patching. These tests use pregenerated, hardcoded test keys for signing. These keys should NEVER be used for any other purpose.
For each profile listed in the config, the test process will:
- Generate a mock OTA based on the specification
- Verify tha original OTA checksum
- Run avbroot against the OTA using
--magisk(with a mock Magisk APK) - Verify the patched OTA checksum
- Extract the AVB-related partitions from the patched OTA
- Run avbroot against the OTA again using
--prepatched - Verify the patched OTA checksum again
The default profiles shipped with the project mimic how various stock OTAs for Pixel devices are built. The generated mock OTAs have valid signatures and data structures for all components, but without any actual data where possible. For example, most files in the ramdisks are empty files. To ensure the mock OTAs cannot be mistakenly installed on a real device, the OTA metadata lists a fake device name in the preconditions section.
Running the tests
To test against the profiles listed in e2e.toml, run:
# To test all profiles
cargo run --release -- test -a
# Or to test against specific profiles
cargo run --release -- test -p pixel_v4_gki -p pixel_v4_non_gki