Files
avbroot/e2e
Andrew Gunnerson 7113fb32ef Add support for outputting zip files with no data descriptors
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>
2024-08-20 21:31:33 -04:00
..

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:

  1. Generate a mock OTA based on the specification
  2. Verify tha original OTA checksum
  3. Run avbroot against the OTA using --magisk (with a mock Magisk APK)
  4. Verify the patched OTA checksum
  5. Extract the AVB-related partitions from the patched OTA
  6. Run avbroot against the OTA again using --prepatched
  7. 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