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.
