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.
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.
Add functions less_than_int() and greater_than_int() that interpret
their args as ints and do the comparison. ("<" and ">" operators, if
implemented, should do string comparison.) This lets us do the build
time check currently done by the check_prereq binary.
A few more changes to edify:
- fix write_raw_image(); my last change neglected to close the write
context, so the written image was corrupt.
- each expression tracks the span of the source code from which it
was compiled, so that assert()'s error message can include the
source of the expression that failed.
- the 'cookie' argument to each Function is replaced with a State
object, which contains the cookie, the source script (for use with
the above spans), and the current error message (replacing the
global variables that were used for this purpose).
- in the recovery image, a new command "ui_print" can be sent back
through the command pipe to cause text to appear on the screen.
Add a new ui_print() function to print things from scripts.
Rename existing "print" function to "stdout".
Adds more edify functions for OTAs:
is_mounted getprop apply_patch apply_patch_check apply_patch_space
write_raw_image write_firmware_image package_extract_file
This allows us to install radios, hboots, boot images, and install
incremental OTA packages.
Fixes a couple of dumb bugs in edify itself:
- we were doubling the size of the function table each time it was
*not* full, rather than each time it was full
- "no such function" errors weren't visible to the parser, so they
didn't prevent execution of the script.
Adds the following edify functions:
mount unmount format show_progress delete delete_recursive
package_extract symlink set_perm set_perm_recursive
This set is enough to extract and install the system part of a (full)
OTA package.
Adds the updater binary that extracts an edify script from the OTA
package and then executes it. Minor changes to the edify core (adds a
sleep() builtin for debugging, adds "." to the set of characters that
can appear in an unquoted string).
Amend (aka the recovery command language) had a half-implemented
scheme of limiting which commands OTA packages were allowed to
execute. It's not clear what this was ever supposed to be good for.
Remove it.
Change the recovery UI so that when there is a hboot or radio update
pending (which the user most do a home+back reboot to actually
install), the UI tells them so, instead of saying "Install from sdcard
complete."
Remove the memory alignment that mysteriously made OTA installs work,
in anticipation of a kernel that fixes the actual problem. Handle
EINTR properly.
In donut, OTA installation often encounters the write() system call
doing short writes -- which is legal but unexpected -- or failing with
ENOSPC when plenty of space is available. Passing aligned memory
buffers to write() appears to prevent (or at least reduce the
frequency) of these problems. b/1833052 has been filed to look at the
underlying problem, but this change aligns buffers we use with write()
so we can OTA for now (or see if this problem still occurs).
minzip fails if write() doesn't write all the data in one call.
Apparently this was good enough before, but it causes OTAs to fail all
the time now (maybe due to the recently-submitted kernel)? Change
code to attempt continuing after short writes.
