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>
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
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: 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.
