Prior to this CL, menu_ is allocated with a fixed length of text_rows_.
However, because we support scrollable menu in wear_ui, there might be
more menu entries than text_rows_, which would lead to out-of-bounds
array access. This CL addresses the issue by switching to std::vector.
Bug: 65416558
Test: Run 'View recovery logs' on angler.
Test: Set large margin height that leaves text_rows less than 21. Then
run 'View recovery logs' with 21 menu entries.
Change-Id: I5d4e3a0a097039e1104eda7d494c6269053dc894
(cherry picked from commit e15d7a5104)
They're mostly identical to the ones in ScreenRecoveryUI, except for the
(legacy) use of 'text_top_'. Because wear_ui.cpp misses the change in
[1] that uses an alternate screen for viewing recovery logs.
Also clean up the included headers.
[1] commit c049163234 ('Add an alternate
screen for viewing recovery logs.').
Test: Build a wearable target recovery; `View recovery logs`.
Change-Id: Ic9208c42a11c037469f5b073ef7d9b721c14d1f3
Prior to this CL, menu_ is allocated with a fixed length of text_rows_.
However, because we support scrollable menu in wear_ui, there might be
more menu entries than text_rows_, which would lead to out-of-bounds
array access. This CL addresses the issue by switching to std::vector.
Bug: 65416558
Test: Run 'View recovery logs' on angler.
Test: Set large margin height that leaves text_rows less than 21. Then
run 'View recovery logs' with 21 menu entries.
Change-Id: I5d4e3a0a097039e1104eda7d494c6269053dc894
Due to the cache size limit for OTA generation, we used to split large
zip files linearly into pieces and do bsdiff on them. As a result, i) we
lose the advantage of imgdiff; ii) if there's an accidental order change
of some huge files inside the zip, we'll create an insanely large patch.
This patch splits the src&tgt more smartly based on the zip entry_name.
If the entry_name is empty or no matching source is found for a target
chunk, we'll skip adding its source and later do a bsdiff against the
whole split source image (this rarely happens in our use cases except
for the metadata inside a ziparchive).
After the split, the target pieces are continuous and block aligned,
while the sources pieces are mutually exclusive. (Some of the source
blocks may not be used if there's no matching entry_name in the target.)
Then we will generate patches accordingly between each split image
pairs.
Afterwards, if we apply imgpatch to each pair of split source/target
images and add up the patched result, we can get back the original
target image.
For example:
Input: [src_image, tgt_image]
Split: [src-0,tgt-0; src-1,tgt-1, src-2,tgt-2]
Diff: [ patch-0; patch-1; patch-2]
Patch: [(src-0,patch-0)=tgt-0; (src-1,patch-1)=tgt-1;
(src-2,patch-2)=tgt-2;]
Append: [tgt-0 + tgt-1 + tgt-2 = tgt_image]
Peformance:
For the small package in b/34220646, we decrease the patch size of
chrome.apk dramatically from 30M to 400K due to the order change of
two big .so files.
On two versions of angler, I also observe decent patch size decrease.
For chrome.apk, we reduced the size from 5.9M to 3.2M; and for
vevlet.apk from 8.0M to 6.5M.
Bug: 34220646
Test: recovery component test && apply imgdiff & imgpatch on two
chrome.apk
Change-Id: I145d802984fa805efbbac9d01a2e64d82ef9728b
It's covered by the equivalent variable in ScreenRecoveryUI:
GRSurface* error_icon;
Also refactor WearRecoveryUI::draw_background_locked() to get it
closer to ScreenRecoveryUI code.
Test: Build a wearable target recovery; Run graphics test.
Change-Id: I3a8d0e4dbf6fe170e4f3adde7eaf4a2043132a57
Turn on -Wall for all modules. Also remove the obsolete file_cmp() in
apply_patch test and now() in wear_ui.
The only exception is lib_edify due to the unused functions in the
intermediate cpp files generated from the lex files. It will be handled
in a seperate CL.
Bug: 64939312
Test: mma, unit tests pass
Change-Id: Ic53f76b60b6401ab20db3d98130d674c08e3702f
Tao Bao
Tianjie Xu
Bill Yi
TreeHugger Robot