Update build fingerprint to match nakasi (Nexus 7 2012) KTU84P

Change-Id: I70a24695d50c67d7d05c8b34c765061cf2fa58f8
recovery: add a "rescue mode" (SD-boot recovery managing an eMMC install)

Recoveries which boot off SD card, but manage an eMMC install are
indispensable for recovering from certain catastrophes.  It's useful to
be able to create such a "rescue" recovery image without having to
modify the recovery initramfs; to facilitate this, check for a flag
under /boot on startup and operate on eMMC regardless of boot location
if it's present.

Change-Id: I95b5523a1371833b405c17dfbdc7b6475c82fad0
Move recovery_emmc_protect.sh script under recovery/

Change-Id: I47cdbb666c233693b326652f826b54fb510384ed
Support extending postrecoveryboot.sh via scripts on /boot

This allows special-purpose script-driven recovery images to perform
last-minute tasks, such as copying an OTA package that needs to be able
to unmount all filesystems to /tmp, before starting the recovery
operation.

Change-Id: I1b7f18c6fb039590cbda93a2dddb41a3d0b7173a
Handle the bootloader control block properly

The BCB is not just a flag -- it's a data structure laid out as follows
(bootable/recovery/bootloader.h):

struct bootloader_message {
    char command[32];
    char status[32];
    char recovery[1024];
};

Update the BCB as such instead of on an ad-hoc basis; once we do that,
we can allow the recovery to manipulate the BCB directly, which allows
automatic resumption of recovery tasks interrupted by a crash or power
failure.

Change-Id: Ib35cecad311faba889c5954288fd091efef73a7a
recovery: add support for command files in /boot

Android recoveries accept a list of commands to perform on startup in
/cache/recovery/command; while this is a good location for an installed
system to communicate with a recovery, it doesn't work for creating
special-purpose script-driven recovery images (for initial install or
repartitioning, for example).

As a solution, introduce a command file in /boot (we have to be able to
ship files in /boot to have a recovery image anyway, so this is a
natural place to put it), and copy the arguments from that file to the
bootloader control block on recovery startup so that they'll be picked
up.

Change-Id: Ic06850d02ef7d6f59f6ae99f3d0eef79b82e1857
recovery: move device init code into init.rc from postrecoveryboot.sh

The CM recovery doesn't invoke postrecoveryboot.sh, so if we ever want
to use that recovery, we need to get the basic device init code out of
postrecoveryboot.sh.  init.recovery.${ro.hardware}.rc is used by all
known recoveries (it's part of AOSP), so let's put the device init stuff
there instead.

Change-Id: Ib6cd279c6fb1f2a4072490b1e16ebcd59fb61467
Don't allow unmounting of /rom via the recovery UI

/rom needs to stay mounted for BCB updating (notably, setting the
reboot-recovery flag) to work correctly.  There's normally no need to
unmount it, so remove the option from the UI entirely.

Change-Id: I26f1da1b1b11772263ab975b79b834b80a4438e3
recovery: fix command-files-on-/boot support for rescue mode

With a rescue mode boot, any command files or postrecoveryboot.sh
extensions would be on the SD card, but by the time postrecoveryboot.sh
runs, /dev/block/by-name/boot already points to eMMC.  Instead, detect
this case and handle it specially in postrecoveryboot.sh.

Change-Id: I17e28ca0cb89abcd12d86f0243ad639766b89c48
configure_vold.sh: use symlink instead of property to detect SD installs

In recovery rescue mode, we want everything set up as if it were an eMMC
install, even though we booted off SD card.  Since the
ro.boot.bootdevice property can't be changed for rescue mode, we need to
use the /dev/block/by-name symlinks to determine whether we want to
configure vold for an SD card install instead.

Change-Id: I2a054f81521f8ba09335adfe5084bb6b1dc6454d
etc: media_codecs: alter video encoder and decoder priority

720P codecs are always used irrespective of the codec capability
required for encode or decode. Reorder to use the 720P codecs only
when the generic encoder and decoder fails.

Change-Id: Ie98dad121a75817b8ef81990192a0e5c9a2055c8
Storage configuration changes in preparation for repartitioning

* Limit SD card file size to 4 GB -- SD card is expected to be FAT32
* Disable mass storage access for eMMC, since we can't support mass
  storage for emulated volumes
* Mark eMMC as nonremovable

Change-Id: I2f70004ef74c096465dcce0ba45bff3bc7adef22