The apply patch test should have a deterministic way to append patch
data. Add debug logs to dump the length and SHA1 of each step to further
track down the flakiness.
Also redirect the debug logging to stdout in case the logcat becomes too
chatty.
Bug: 67849209
Test: Run recovery_component_test
Change-Id: I42bafef2d9dee599719ae57840b3d8c00d243ebd
This allows the update_verifier in a general system image to work across
devices that have different verified boot versions (i.e. not supported /
verified boot 1.0 / verified boot 2.0 / disabled).
Bug: 78283982
Test: Run recovery_component_test on both of marlin and walleye.
Test: Generate an OTA that has this CL. Install this OTA and check the
update_verifier log during the post-reboot verification, on both
of marlin (VB 1.0) and walleye (VB 2.0).
Test: Build and flash walleye image with verified boot disabled. Check
that update_verifier marks the slot as successfully booted.
Change-Id: I828d87d59f911786531f774ffcf9b2ad7c2ca007
As they're accepting the SinkFn callback, it makes more sense to leave
the work to their callers.
Test: mmma -j bootable/recovery
Test: Run recovery_component_test on marlin.
Test: No other active user of the two functions.
Change-Id: I8d67b38ce037925442296f136b483e0c71983777
After splitting the previously flaky
ApplyPatchModesTest#PatchModeEmmcTarget tests,
PatchModeEmmcTargetWithMultiplePatches now becomes the sole victim. This
CL dumps additional info to narrow down the cause.
Bug: 67849209
Test: `recovery_component_test` on marlin.
Test: It dumps additional info after using corrupt bonus.file.
Change-Id: Ic5436de457cc882a51d03f49d5cee70077f7d3df
Although the tests were initially written for checking the validity of
the text images, it doesn't hurt to run them continuously as part of the
component test (recovery_manual_test requires reboots during the run,
due to the nature of the tests of recovery-{refresh,persist}). This also
allows detecting breaking changes to libminui or libpng.
There's a catch that the ResourcesTest won't be triggered via `atest`,
as the res-* testdata won't be picked up via AndroidTest.xml. Explored
a few options but not addressing that in this CL:
- `atest` is not fully working in AOSP yet (missing support in
tools/tradefederation/core/atest/atest.py).
- `atest` doesn't allow specifying the testdata with path in the 'push'
option.
- It won't fail the test run though, as ResourcesTest will skip the
tests automatically when it finds no text image file.
- APCT and manual `adb sync data` are not affected, and I don't see an
active user of `atest` other than a tool for manual test invocation.
- Unrelated to this CL, `atest` doesn't seem to work well with
recovery_component_test or recovery_unit_test while we have both of
them in one AndroidTest.xml. It randomly triggers only one of them,
despite of the given test name. When splitting AndroidTest.xml into
two, it tends to pick up the wrong testdata subdir and gives wrong
results.
Test: Run recovery_manual_test and recovery_component_test on marlin.
Change-Id: I3a237499a7770356e14085674bc8b9cb4551db85
As a private header for testing purpose. PngHandler additionally loads a
given filename if the one with '/res/images' prefix is not available. It
also provides color_type/bit_depth that are parsed from the PNG file.
This allows reusing the same code for the ResourcesTest (renamed from
ResourceTest).
Test: Run recovery_manual_test on marlin.
Change-Id: I3f939d79a1cb1b83a899847dbe2d51bde15d16d8
We set the limit of the max stash size to 80% of cache size. But the
cache space can still be insufficient for the update if the log files
occupy a large chunk of /cache. So remove the old logs for now to make
room for the update.
Bug: 77528881
Test: unit tests pass
Change-Id: Ia8bcb0ace11f8164ad9290bfb360e08e31d282cb
