We already know the flakiness happens in bspatch, and the issue is
tracked in b/80193170.
Bug: 67849209
Test: unit tests pass
Change-Id: Ib4772b8f2f0225125096fe7407d083b5bb542cfb
It used to return a Value blob to be consumed by sha1_check() (which has
been deprecated). Currently there's no other generic updater function
that works with BLOB Values. This CL changes read_file() to return a
string Value to make it more useful (e.g. allowing equality check).
Test: Run recovery_component_test and recovery_unit_test on marlin.
Change-Id: Iba986ba649030112babefe898f26aa9ffe69eeb7
Also simplify the helper function expect() in {edify,updater}_test.cpp.
Test: Run recovery_component_test on marlin.
Change-Id: If54febba4b5013f6d71546318a1ca6b635204ac8
Test: mmma -j bootable/recovery
Test: Run recovery_component_test and recovery_unit_test on marlin.
Change-Id: I4b240e3e771c387b9694be9c0f2f74e0265ab4cb
Also fix an error-pone behavior in previous code when verifying an eMMC
target. As long as it loads the partition content successfully according
to the SHAs embedded in the filename, it shouldn't further check against
the SHAs given in the second argument. Because the loaded contents
relate to a specific partition size.
For example:
apply_patch_check(
"EMMC:/boot.img:src_size:src_hash:tgt_size:tgt_hash",
"src_hash");
Assume "/boot.img" already has the desired hash of "tgt_hash", the
previous code would give wrong verification result. The issue can be
addressed by additionally listing "tgt_hash" as one of the desired SHAs
(or by applying this CL).
Bug: 110106408
Test: Run recovery_unit_test and recovery_component_test on marlin.
Change-Id: I8daafdbecd083f687e24d563ab089caa25667633
Note that the code exists in debugging path only, and won't be hit
unless device has flaky flash.
Test: Run recovery_unit_test and recovery_component_test on marlin.
Change-Id: I0c71adc271f08f00e3eabd9d14cd8af3186c5bae
The matching edify function has been removed from EdifyGenerator [1]. In
theory device-specific releasetools script may still use this function,
but it no longer looks useful. Because a) we should use range_sha1()
when asserting the SHA-1 hash of a block device; b) we should look into
the contents when asserting a text file.
[1] https://android-review.googlesource.com/c/platform/build/+/714104
Test: Run recovery_component_test on marlin.
Test: Code search shows no active user.
Change-Id: Id39439101534fb89cf8c5cea80a4b758c8a1a60d
This will be used for testing purpose only, replacing the previously
used "fail", to intentionally abort an update.
As we're separating the logic between commands parsing and execution,
"abort" needs to be considered as a valid command during the parsing.
Test: recovery_unit_test and recovery_component_test on marlin.
Change-Id: I47c41c423e62c41cc8515fd92f3c5959be08da02
... into unit/applypatch_test.cpp. And rename the file to
component/applypatch_modes_test.cpp.
Bug: 110106408
Test: Run recovery_unit_test and recovery_component_test on marlin.
Change-Id: Ic23c4f054baa2fa0d5e8ea2fcffd22572f1f112e
If two consecutive call are made to drmModePageFlip, the second call
may fail with -EBUSY because the first flip is not completed yet.
This patch adds a wait for completion mechanism based on
drmHandleEvent.
Change-Id: Ied13ebefc7523003431b1b307bae70d1a70cb24b
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Benoit Fradin <benoit.fradin@intel.com>
During block verification, load stash reads from the source blocks on
the device instead of the stashed files. And for interrupted update,
it's pretty common that the source blocks has already been overwritten
by subsequent commands.
In that case the hash printing is mostly useless. Moreover we should have
already printed the hash when the first update failed.
Bug: 80241799
Test: Unit tests pass. No longer prints mismatching stashed source blocks on retry.
Change-Id: I4effe684280b0325199f6cc4b2cc26e91295c2d7
Tao Bao
Tianjie Xu
Jeremy Compostella
Treehugger Robot