For A/B devices, "view recovery logs" doesn't work due to the lack
of cache partition. To help debugging, we'll show /tmp/recovery.log
instead if /cache is not found.
Change-Id: Idb77c3a4c30388148a210b38d732a7b27e757bba
Test: Tested on an A/B device and /tmp/recovery.log showed up.
Bug: 30905700
This missing header is needed to use PRIu64 macros.
Bug: 27178350
TEST=`mma bootable/recovery` on the failing branch.
Change-Id: I165701e8019256426d3f6a4168db52c6a0197c4d
This missing header is needed to use PRIu64 macros.
Bug: 27178350
TEST=`mma bootable/recovery` on the failing branch.
Change-Id: I165701e8019256426d3f6a4168db52c6a0197c4d
If mount fails and the partition has the formattable flag set in fstab
it is formatted and another attempt at the mount is made.
Change-Id: I44edafac7d7ff663489072c66b7e210466316b14
This patch enables sideloading an OTA on A/B devices while running from
recovery. Recovery accepts the same OTA package format as recent
versions of GMS, which consists of .zip file with the payload in it.
Bug: 27178350
TEST=`adb sideload` successfully a full OTA (*)
TEST=Failed to take several invalid payloads (wrong product,
fingerprint, update type, serial, etc).
<small>(*) with no postinstall script.</small>
Change-Id: I951869340100feb5a37e41fac0ee59c10095659e
The fopen_path will fail here e.g. if /cache is corrupt and could
not be mounted. Not properly handling an error code from
fopen_path() results in a boot loop into recovery as fwrite() on
a NULL FILE object will crash the recovery app.
Change-Id: I1ccff5a8cb620a32f32adfe97a3fae8e5e908f39
[root cause ] miniui has no mechanism to protect
the buffer which is displaying
[changes ] recovery
[side effects] ui show
[self test ] sc9850-2 general operation has not display abnormal
[reviewers ] xinglong.zhu
Signed-off-by: xinglong.zhu <xinglong.zhu@spreadtrum.com>
[change_type ] AOB --> google_original
[tag_product ] common
Change-Id: I989a0b2943ff6070a0e98718cfbe95144510d3a2
A Certificate is a pair of an RSAPublicKey and a particular hash. So v1
and v3 differ in the hash algorithm (SHA-1 vs SHA-256), similarly for
v2 and v4.
In verifier testcases, we used to load v1/v2 keys with an explicit
argument of "sha256" to test the v3/v4 keys. This CL switches to loading
v3/v4 keys directly and lets load_keys() to handle that, which is the
actual flow we use in practice.
Also remove the "fallback to v1 key" in the testcases, which is not the
actual behavior.
Bug: 30415901
Test: Run the verifier_test component test on device.
Change-Id: I3a2baa64826f1b6c4c367a560090df384c4521bb