(This is being cherry-picked from master.)
hboot will apparently fail to install if the first block of the image
(the one pointed to by the offset in the block 0 header) is a bad
block. (Hopefully it handles subsequent bad blocks.)
This change makes the MTD write code keep track of the bad blocks it
has skipped over, so that the offset in the header can be adjusted to
be the address of the first successfully written block.
http://b/2358012 - passion: failure to flash hboot (bad blocks?)
When using the hidden menu to wipe data in recovery, confirm before
starting the wipe. (This does not affect booting with the --wipe_data
flag, or using Alt+W on dream with the menu hidden -- those still wipe
data immediately.)
Reduce the fraction of the progress bar used for package verification
from 50% to 25%:
- verification is faster than before due to sha1 improvements
- in eclair we're now verifying the compressed data rather than
decompressing it
- incremental packages (which is what most installs use) write more
data than is contained in the package.
The symlink() function should remove existing files before creating
symlinks, so scripts are idempotent. Log messages when various system
calls fail (but don't make the whole script fail).
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).
With the recovery image being installed by applypatch, the flash_image
tool isn't needed any more. Continue to build it for eng just in case
it's handy for debugging.
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.
Yank all the code to install OTA packages out of the recovery binary
itself. Now packages are installed by a binary included in the
package (run as a child of recovery), so we can make improvements in
the installation process without waiting for a new release to use
them.
We fail to detect certain bad blocks (marked in the factory as bad, I
think?) when reading mtd partitions. These come back as a block of
all zeros. Since it's fairly unlikely a legitimate boot or recovery
block will contain 128k of zeros, change mtdutils to skip over such
blocks.
Arve says https://review.source.android.com/10535 may be a long-term
fix for this, but he isn't yet sure.
updater (which is only needed in OTA packages) is getting included in
/system/bin, where it just takes up (quite a bit of) space. Use the
hack of including it only in eng builds so it's not there for user
builds.
Let recovery accept set_progress commands to control progress over the
'current segment' of the bar. Add a set_progress() builtin to the
updater binary.
Allow devices (in BoardConfig.mk) to define additional static
libraries to be linked in to updater, to make device-specific
functions available in edify scripts. Modify the updater makefile to
arrange for device libraries to register their edify functions.
Some devices want to do special things when recovery wipes data (eg,
wipe data in their baseband processor as well). Add a hook in the
device-specific recovery library that gets called when data is wiped.
Also add an amend root for the "mbm" partition.
Add a function to read a property from a ".prop"-formatted file
(key=value pairs, one per line, ignore # comment lines and blank
lines). Move ErrorAbort to the core of edify; it's not specific to
updater now that errors aren't stored in the app cookie.
To do a firmware-install-on-reboot, the update binary tells recovery
what file to install before rebooting. Let this file be specified as
"PACKAGE:<foo>" to indicate taking the file out of the OTA package,
avoiding an extra copy to /tmp. Bump the API version number to
reflect this change.
