We have a general need for overriding more paths (e.g. "/tmp"), mostly
for testing purpose. Rename CacheLocation to Paths, and use that to
manage TEMPORARY_{INSTALL,LOG}_FILE.
Test: mmma -j bootable/recovery
Test: recovery_component_test
Change-Id: Ia8ce8e5695df37ca434f13ac4d3206de1e8e9396
Dump the SHA1 of the uncompressed data in applypatch to confirm if we
are at least doing the bspatch part correctly. (I expect so since the actual
length of the uncompressed data matches the expected length).
Also try to decompress the deflate chunk inside the recovery image for
these two flacky tests. In theory, there shouldn't be randomness in
zlib; so we would know if we process the data wrongly if the deflate fails
to decompress.
Bug: 67849209
Test: recovery_component_test
Change-Id: Id947522153b1eeb0d10d161298a96fb045f92018
This resource files are used in tests. ota package zip file
contains only text files.
Config files are generated using tools/gen_update_config.py
Test: N/A
Change-Id: I9d3d0f81472dc20db18b32f4a9445a998b68b0e3
Signed-off-by: Zhomart Mukhamejanov <zhomart@google.com>
gen_update_config.py generates JSON config files
from given OTA image zip files.
README.md is updated.
Test: manually
Change-Id: Ifd09b49a73983a42752ee3842a566cecedb9cae0
Signed-off-by: Zhomart Mukhamejanov <zhomart@google.com>
To address the warning below (which will be disallowed):
bootable/recovery/updater_sample/tests/Android.mk: warning:
SystemUpdaterSampleTests (java:system) should not link to
android.test.runner (java:platform)
(See b/69899800 or the commit message in [1] for detailed discussions.)
[1]: https://android-review.googlesource.com/c/platform/frameworks/ml/+/666428
Test: `mmma -j bootable/recovery` gives no warning.
Test: Install and run SystemUpdaterSampleTests on device.
Change-Id: I12a1556d572d9f332fcf43dc84cbe8fd1b6df89b
SampleUpdater app was tested manually on a device.
There are unit tests for utility classes.
SampleUpdater app demonstrates how to use Android Update Engine to
apply A/B (seamless) update.
This CL contains demo of non-stream update using async update_engine,
which is accessed directly from an activity.
This app also shows logs from update_engine on the UI.
Instructions can be found in `README.md`.
- Create a UI with list of configs, current version, control buttons and a progress bar
- Add PayloadSpec and PayloadSpecs for working with update zip file
- Add UpdateConfig for working with json config files
- Add applying non-streaming update
Test: tested manually and unit tests for utilities
Change-Id: I05d4a46ad9cf8b334c9c60c7dd4da486dac0400a
Signed-off-by: Zhomart Mukhamejanov <zhomart@google.com>
Bug: 78469201
Test: Wipe from recovery menu, check that wipe is logged correctly
and boot works as expected.
Change-Id: I5bc8ef1b83d78de8b5edba6cc17882edcc744356
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
