Execute mke2fs to create empty ext4 filesystem.
Execute e2fsdroid to add files to filesystem.
Test: enter recovery mode and wipe data
Bug: 35219933
Change-Id: I10a9f4c1f4754ad864b2df45b1f879180ab33876
(cherry picked from commit ac31808cd3)
This is a regression when adding support for margin space in commit
171b4c4c.
We're losing one char when showing long log lines. Because text_ is
aware of kMarginWidth, but not the the added indent (TEXT_INDENT).
Test: 'View recovery logs' on angler, with no missing character.
Change-Id: I284d54681d603e85e69d8e9c25173b1437a704df
Add a new writer that can decode the brotli-compressed system/vendor
new data stored in the OTA zip.
Brotli generally gives better compression rate at the cost of slightly
increased time consumption. The patch.dat is already compressed
by BZ; so there's no point to further compress it.
For the given 1.9G bullhead system image:
Size: 875M -> 787M; ~10% reduction of package size.
Time: 147s -> 153s; ~4% increase of the block_image_update execution time.
(I guess I/O takes much longer time than decompression.)
Also it takes 4 minutes to compress the system image on my local
machine, 3 more minutes than zip.
Test: recovery tests pass && apply a full OTA with brotli compressed
system/vendor.new.dat on bullhead
Change-Id: I232335ebf662a9c55579ca073ad45265700a621e
In a rare case, a random chunk will pass both the gzip header check
and the inflation process; but fail the uncompressed length check in the
footer. This leads to a imgdiff failure. So, we should treat this chunk
as 'normal' instead of 'inflated' while generating the patch.
Bug: 63334984
Test: imgdiff generates patch successfully on previous failing images.
Change-Id: Ice84f22d3653bce9756bda91e70528c0d2f264a0
Move away from taking int* for the Y-offset. Change it to int and return
the offset instead.
Test: Check the recovery menu and 'Wipe data' menu.
Change-Id: Ib15e070a0d576a0f8f66f35605cb8479e7071f26
We're not actually following the gaps as in the comments. For example,
Nexus 6P is supposed to use 220dp and 194dp gaps (top and bottom
respectively), but the actual numbers are 185dp and 194dp. Because the
animation icon and text sizes don't match the ones claimed (animation:
expected 200dp or 700px, actual 800px; text: claimed 14sp, actual 76px).
The top gap changes (shrinks) as we compute the baselines bottom-up.
This CL switches to using computed gaps: the major UI elements always
stay vertically centered, with identical top and bottom gaps.
Bug: 63093285
Test: 'Run graphics test' on angler/volantis/fugu/ryu.
Change-Id: I3cadbb34f728cf034afa47ac02a6deba8cb6b4e7
WearRecoveryUI::draw_progress_locked() has declaration only, where
the definition was deleted in commit
5e7cfb9af6.
WearRecoveryUI::ClearText() is a duplicates of
ScreenRecoveryUI::ClearText().
Test: Build swordfish recovery image. 'Run graphics test' and 'View
recovery logs'.
Change-Id: Ib66955d1d496f04359b4d6487160218e8f954478
The install logging currently assumes that the build number is a 32-bit
integer and prints an error when that doesn't hold true. However, that's
only a convention used by Google builds.
From build/core/version_defaults.mk:
ifeq "" "$(BUILD_NUMBER)"
# BUILD_NUMBER should be set to the source control value that
# represents the current state of the source code. E.g., a
# perforce changelist number or a git hash. Can be an arbitrary string
# (to allow for source control that uses something other than numbers),
# but must be a single word and a valid file name.
#
# If no BUILD_NUMBER is set, create a useful "I am an engineering build
# from this date/time" value. Make it start with a non-digit so that
# anyone trying to parse it as an integer will probably get "0".
BUILD_NUMBER := eng.$(shell echo $${USER:0:6}).$(shell $(DATE) +%Y%m%d.%H%M%S)
endif
Change-Id: I8e7cec0618783f69545ba76d0dce2bbc1681784c
Jin Qian
Treehugger Robot
Tianjie Xu
Tao Bao
Bill Yi
Elliott Hughes
Daniel Micay