GitLab

The default recovery UI will reboot the device when the power key is
pressed 7 times in a row, regardless of what recovery is doing.
Disable this feature during package installation, to minimize the
chance of corrupting the device due to a mid-install reboot.  (Debug
packages can explicitly request that the feature be reenabled.)

Change-Id: I20f3ec240ecd344615d452005ff26d8dd7775acf

RecoveryUI (which is the superclass of ScreenRecoveryUI), provides a
basic CheckKey method that is useful for devices that have KEY_POWER,
KEY_VOLUMEUP, and KEY_VOLUMEDOWN.  Stop overriding it with a less
featureful method; with this no recovery UI customization is needed
for most handheld devices (phones, tablets, etc.).

Change-Id: I7d57cfaaef79afea8af4fc3dbc570afc61aeb5bc

Also provide a default implementation of CheckKey that's reasonable
for many devices (those that have power and volume keys).

Change-Id: Icf6c7746ebd866152d402059dbd27fd16bd51ff8

Change-Id: I5db9987102201c18821acb45d1f824e9865a1451

Convert callback events parameter to unsigned int.

Change-Id: Ife0e983f307c07bf4aca807d70574aeb20c460cd

Also provide a default implementation of CheckKey that's reasonable
for many devices (those that have power and volume keys).

Change-Id: Icf6c7746ebd866152d402059dbd27fd16bd51ff8

Recovery changes:

- add a method to the UI class that is called when a key is held down
  long enough to be a "long press" (but before it is released).
  Device-specific subclasses can override this to indicate a long
  press.

- do color selection for ScreenRecoveryUI's menu-and-log drawing
  function.  Subclasses can override this to customize the colors they
  use for various elements.

- Include the value of ro.build.display.id in the menu headers, so you
  can see on the screen what version of recovery you are running.

Change-Id: I426a6daf892b9011638e2035aebfa2831d4f596d

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

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.