| Commit message (Collapse) | Author | Files | Lines |
|
NextCheckKeyIsLong() is called right before each call to CheckKey() to
tell the implementation if the key is a long-press or not. (To be
used on devices with few buttons.) It's done as a separate method
(rather than a parameter to CheckKey) to not break existing recovery
UI implementations.
EnqueueKey() can be called from CheckKey() to put arbitrary code codes
in the synchronous queue (to be processed by HandleMenuKey).
Change-Id: If8a83d66efe0bbc9e2dc178e5ebe12acd216324b
|
|
Zip install works, had to move mincrypt code into TWRP to prevent
a crash when checking the zip signature.
Added wipe functions
Made it compile in CM7
Made text show up in console and logging
|
|
Change-Id: Id182bb95ffcc475c5acabb29b413e422302ae7f2
|
|
Change-Id: Id182bb95ffcc475c5acabb29b413e422302ae7f2
|
|
Move the key for handling keys from ScreenRecoveryUI to RecoveryUI, so
it can be used by devices without screens. Remove the UIParameters
struct and replace it with some new member variables in
ScreenRecoveryUI.
Change-Id: I70094ecbc4acbf76ce44d5b5ec2036c36bdc3414
|
|
Move the key for handling keys from ScreenRecoveryUI to RecoveryUI, so
it can be used by devices without screens. Remove the UIParameters
struct and replace it with some new member variables in
ScreenRecoveryUI.
Change-Id: I4c0e659edcbedc0b9e86ed261ae4dbb3c6097414
|
|
Move all the functions in ui.c to be members of a ScreenRecoveryUI
class, which is a subclass of an abstract RecoveryUI class. Recovery
then creates a global singleton instance of this class and then invoke
the methods to drive the UI. We use this to allow substitution of a
different RecoveryUI implementation for devices with radically
different form factors (eg, that don't have a screen).
Change-Id: I76bdd34eca506149f4cc07685df6a4890473f3d9
|
|
Change-Id: I423a23581048d451d53eef46e5f5eac485b77555
|
|
Change-Id: I68a67a4c8edec9a74463b3d4766005ce27b51316
|
|
Change-Id: I6d52fd1db27fdf1b61f41f598a2209b70385b106
|
|
Events are now delivered through a callback mechanism during
a call to ev_dispatch(). This will allow us to extend the events
code to handle other devices/fds, not just input. One such example
is the ability to process uevents.
During initialization, we provide an input callback to ev_init
that gets called when a new event is encountered during dispatch.
ev_get has been removed and replaced with ev_get_input() helper
function that can be called from inside the callback to attempt
to get an input event.
The existing client of ev_get in recovery has been split up such
that the input thread just calls ev_wait(); ev_dispatch(); and
the input_callback handles individual events by using the
ev_get_input() helper.
Change-Id: I24d8e71bd1533876b4ab1ae751ba200fea43c049
Signed-off-by: Dima Zavin <dima@android.com>
|
|
Change-Id: I912d3ab32973c5c5e7b6b1749698f8a71d884fa3
|
|
Change-Id: Iabe8be5bbfa7d2bf1d13280c8734ff75b62a152f
|
|
The new android_reboot() function is a nicer way to reboot the
system. I can optionally sync() and remount read-only writable
filesystems. This fixes bug 3350709.
Change-Id: Ic4c8676debd642e57bce3107b99dd810d90b6f82
|
|
(Cherry-pick back from master.)
Bug: 4071007
Change-Id: I28355c593770df678968185171bdd19dabe7f062
|
|
Change-Id: Icba35da91167d30c446581afb47d0804e49964bf
|
|
Also remove the weird backwards compatibility thing for animations
with fewer than 10 frames. Frames are always named "name01.png",
"name02.png", ..., no matter how many there are.
Change-Id: I7af64fdec1bfcdb0464998b735ec8d6c626ffe9d
|
|
Change some of the UI parameters (# of indeterminate progress bar
frames, fps, etc.) from #defined constants to variables that can be
set by the device-specific recovery_ui code (via a new function).
Support overlaying different images on top of the base installation
icon to animate it. Make the FPS control more accurate.
Change-Id: I9268b389b7ea6b3ed9e0c7eae37baf4272e60edd
|
|
If recovery sits for 2 minutes in prompt_and_wait(), and you've never
turned the screen on via the magic keypress, go ahead and reboot. (We
used to assume that the user could pull the battery to get out of this
state, but on devices with nonremovable batteries...)
If you've ever enabled display of the log/menu since recovery started,
we assume you know what you're doing and will stay in recovery until
you choose to reboot.
Bug: 3387873
Bug: 3387274
Change-Id: I041621e5db132df9a925e6808845a7c45e1b427a
|
|
Let applypatch read and write EMMC partitions as well as MTD ones.
This enables incremental updates that include boot image changes, as
well as OTA of new recovery partitions.
Change-Id: Ib1861219c7ca66dff29ad02d6a0a14e5f03eb4d8
|
|
Make the mount and format functions take extra parameters describing
the filesystem type and add support for mounting and formatting ext4
filesystems on EMMC.
Change recovery to consistently use stdout for status messages instead
of mixing stdout and stderr.
|
|
Replaces the "install sdcard:update zip" menu option with one that
displays a menu of zip files (and subdirs) on the sdcard and lets you
pick which one to install.
Change-Id: Icff541525f2fdfc8939a91af626ecc386ac9dd07
|
|
Change-Id: Ie6c6c920260dfa759fbb15b1f352d6bb0fa7146c
|
|
Change-Id: I46e4d7fe76e4219207e46f19e50188e38bb932b7
|
|
Change-Id: I008510bf614606a46a630c7adc39464ce1143ec3
|
|
Let applypatch read and write EMMC partitions as well as MTD ones.
This enables incremental updates that include boot image changes, as
well as OTA of new recovery partitions.
Change-Id: I3766b9e77c639769ddf693b675da51d57f6e6b1d
|
|
Make the mount and format functions take extra parameters describing
the filesystem type and add support for mounting and formatting ext4
filesystems on EMMC.
Change recovery to consistently use stdout for status messages instead
of mixing stdout and stderr.
|
|
Replaces the "install sdcard:update zip" menu option with one that
displays a menu of zip files (and subdirs) on the sdcard and lets you
pick which one to install.
Change-Id: I85c94c0e9bc8e05ca52031fc29ca2624c2695ced
|
|
Remove support for the HTC-specific "firmware" update command and the
corresponding edify function write_firmware_update(). This
functionality is now done by an edify extension library that lives in
vendor/htc.
Change-Id: I80858951ff10ed8dfff98aefb796bef009e05efb
|
|
|
|
Instead of six separate images for the left end, right end, and tiled
center portion of the full and empty progress bars, just use two
images: a full bar and an empty bar. Draw the left side of the full
bar and the right side of the empty one, moving the boundary rightward
to "fill" the bar. This makes recovery trivially smaller, and allows
fancier images to be used as progress bars.
Support paletted PNG images as resources.
|
|
If the a recovery icon file is so short that we can't even read the
8-byte header, put a message in the log but not on the device screen.
We intentionally have zero-length files for some icons on some devices,
if they're never shown (eg, the firmware installation icons are only
used on HTC devices).
|
|
gcc 4.4 complains about some of the recovery ui functions not being
declared. To include the header, we have to fix the 'volatile'
declaration (otherwise there's a compiler error).
Move the dream-specific images to vendor/htc/dream, make the default
images a generic phone.
|
|
Take some device-specific details of the recovery UI (eg, what keys to
press to bring up the interface and perform actions, exact text of the
menu, etc.) and split them out into separate C functions. Arrange to
take implementations of those functions from the appropriate vendor
directory at build time. Provide a default implementation in case no
vendor-specific one is available.
|
|
Original author: dougz
Merged from: //branches/donutburger/...
Automated import of CL 144105
|
|
Automated import of CL 144082
|
|
|
|
|
|
|