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
(cherry picked from commit 3250f72360)
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
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
Merged-In: I10a9f4c1f4754ad864b2df45b1f879180ab33876
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