'-Wimplicit-function-declaration' is not needed (it's for C89) and
already enabled by -Wall.
For '-Wno-missing-field-initializers', don't see any existing case that
requires the flag.
Test: `mmma -j bootable/recovery` on aosp_{bullhead,marlin}-userdebug.
Change-Id: I46604723087ed9a7747f6cae31a95fc0074c6758
It used to be "const Value*", but nullptr won't be a valid input.
Test: recovery_host_test; recovery_component_test
Change-Id: I904b5689ac3e64504088bf0544c9fb5d45a52243
Prior to this CL, the block verification works were assigned based on
the pattern of the ranges, which could lead to unbalanced workloads. This
CL adds RangeSet::Split() and moves update_verifier over.
a) For the following care_map.txt on walleye:
system
20,0,347,348,540,556,32770,33084,98306,98620,163842,164156,229378,229692,294914,295228,524289,524291,524292,524348,529059
vendor
8,0,120,135,32770,32831,94564,98304,98306
Measured the time costs prior to and with this CL with the following
script.
$ cat test_update_verifier.sh
#!/bin/sh
adb shell stop
adb shell "cp /data/local/tmp/care_map.txt /data/ota_package/"
for i in $(seq 1 50)
do
echo "Iteration: $i"
adb shell "bootctl set-active-boot-slot 0"
adb shell "echo 3 > /proc/sys/vm/drop_caches"
adb shell "time /data/local/tmp/update_verifier"
sleep 3
done
Without this CL, the average time cost is 5.66s, while with the CL it's
reduced to 3.2s.
b) For the following care_map.txt, measured the performance on marlin:
system
18,0,271,286,457,8350,32770,33022,98306,98558,163842,164094,196609,204800,229378,229630,294914,295166,501547
vendor
10,0,42,44,85,2408,32770,32806,32807,36902,74242
It takes 12.9s and 5.6s without and with the CL respectively.
Fixes: 68553827
Test: recovery_unit_test
Test: Flash new build and trigger update_verifier. Check the balanced
block verification.
Change-Id: I5fa4bf09a84e6b9b0975ee5f522724464181333f
The function ApplyBSDiffPatch() defined in bspatch.cpp is declared in
applypatch.h, but it includes "bspatch.h" from the bsdiff/ project,
which is at least confusing. There is no "bspatch.h" in this repo, so
the include actually reffers to the one in bsdiff. This patch uses the
"bsdiff/bspatch.h" form instead to avoid confusion.
Bug: None
Test: It builds.
Change-Id: I6b6ffd6725b2b34ff644aed93683f69779103661
We used to CHECK and abort on parsing errors. While it works fine for
the updater use case (because recovery starts updater in a forked
process and collects the process exit code), it's difficult for other
clients to use RangeSet as a library (e.g. update_verifier).
This CL switches the aborts to returning empty RangeSet instead. Callers
need to check the parsing results explicitly.
The CL also separates RangeSet::PushBack() into a function, and moves
SortedRangeSet::Clear() into RangeSet.
Test: recovery_unit_test
Test: Sideload an OTA package with the new updater on angler.
Test: Sideload an OTA package with injected range string errors. The
updater aborts from the explicit checks.
Change-Id: If2b7f6f41dc93af917a21c7877a83e98dc3fd016
This CL mainly changes:
a) moving the interface in struct provider_vtab to std::function;
b) code cleanup, such as moving the declaration closer to the uses,
using explicit type conversion.
Test: recovery_component_test
Test: minadbd_test
Test: Sideload a package on marlin.
Change-Id: Id0e3c70f1ada54a4cd985b54c84438c23ed4687e
We encountered segfaults in Imgdiff host tests due to the failure to
reset states of getopt. The problem can be solved by switching to use
bionic's gtest where a new process is forked for each test.
Also modify the recovery_component_test to make sure it runs in parallel.
Changes include:
1. Merge the writes to misc partition into one single test.
2. Change the hard coded location "/cache/saved.file" into a configurable
variable.
Bug: 67849209
Test: recovery tests pass
Change-Id: I165d313f32b83393fb7922c5078636ac40b50bc2
After removing some deadcode from libext4_utils, libz is optimized
out by linker. However, it's still required by libvintf. Moving libz
down the list fixed the build.
Bug: 64395169
Change-Id: I23ecd70c83af83a219faced59d8227dc3c4e43d5
It would clang-format according to the local style file in
.clang-format, unless explicitly skipped with --no-verify.
An example output is as follows:
[COMMIT dda6b1ee4247] test
[FAILED] clang_format
The following files have formatting errors:
screen_ui.cpp
You can run `/mnt/aosp/aosp-master/tools/repohooks/tools/clang-format.py --fix --clang-format /mnt/aosp/aosp-master/prebuilts/clang/host/linux-x86/clang-stable/bin/clang-format --git-clang-format /mnt/aosp/aosp-master/prebuilts/clang/host/linux-x86/clang-stable/bin/git-clang-format --style file --commit dda6b1ee424710760bbab4421e95239fa6a2b40d` to fix this
[COMMIT be69a2c4ba16] Add a repohook to clang-format the change.
[RUNNING 2/2] clang_format
An automatic fix can be attempted for the "clang_format" hook. Do you want to run it? (Yes/no)?
Fix successfully applied. Amend the current commit before attempting to upload again.
More details about repohooks can be found at:
https://android.googlesource.com/platform/tools/repohooks/
Test: `repo upload` a CL.
Change-Id: Ie8203a317eb3be7acd5592e03374873997647aa0
~TemporaryDir() calls rmdir(2) directly, which works with empty
directories only.
Test: Run recovery_host_test; No leftover on host.
Test; Run recovery_component_test on marlin; No leftover on device.
Change-Id: Ib510efb16eeda61b34161e2b386499e6cb79a4ca
As we construct the deflate entries of the target zip file with
random data, the total size of the zip file may vary from case
to case. This leads to occasional failures in the split test for
deflate large apk files. This CL fixes the issue by adding two static
zip files in the testdata instead of generating them dynamically.
Bug: 67849209
Test: run the deflate_large_test repeatedly
Change-Id: Iaeffad9205adefa10c9f62f9f088c33c4360a650
'group_range_count' doesn't properly consider the pair-wise range
structure. It may split the ranges into wrong pairs if it evaluates to
an odd number.
For example, for an input range string of "6,0,2,10,12,20,22" with 4
threads, group_range_count becomes 1. It would then try to verify (0,2),
(2,10), (10,12) and (12,20). Note that (2,10) and (12,20) are not valid
ranges to be verified, and with (20,22) uncovered.
Bug: 68343761
Test: Trigger update_verifier verification. Check the number of verified
blocks against the one in care_map.txt.
Change-Id: I7c5769325d9866be06c45e7dbcc0c8ea266de714
