GitHub PushEvent at 2014-05-26 08:37:27
Repository: android_device_bn_encore
Actor: steven676
Payload: {"shas":[["708c16dafbc3a0230b752c33299362943dead36f","4068f0880b399410602d694b3cc711c8a8f4727e@steven676.net","media_codecs.xml: enable ffmpeg-based software decoders\n\nChange-Id: I60cf75f39abb9f3ad4c6689711dacefbd0ba4b56","Steven Luo",true],["7ffcc276c3f3d627932f9e790a98c31c41a9552e","4068f0880b399410602d694b3cc711c8a8f4727e@steven676.net","Report GPS and microphone present\n\nWhile these items of hardware are not required by the Android CDD, the\nfact that requesting the ACCESS_FINE_LOCATION and RECORD_AUDIO\npermissions implies a requirement for the hardware (unless otherwise\nstated in the app's manifest) makes life difficult for us unless we\nreport the hardware present.\n\nChange-Id: Ib34d27e19c9e6f9fbce3b6042e2618debc24e6df","Steven Luo",true],["9b9c228b21a75117aee75bc834ed5cdebe37120a","4068f0880b399410602d694b3cc711c8a8f4727e@steven676.net","recovery: add a \"rescue mode\" (SD-boot recovery managing an eMMC install)\n\nRecoveries which boot off SD card, but manage an eMMC install are\nindispensable for recovering from certain catastrophes.  It's useful to\nbe able to create such a \"rescue\" recovery image without having to\nmodify the recovery initramfs; to facilitate this, check for a flag\nunder /boot on startup and operate on eMMC regardless of boot location\nif it's present.\n\nChange-Id: I95b5523a1371833b405c17dfbdc7b6475c82fad0","Steven Luo",true],["b531aaf832de462938cddec08f2671bbbdd5a947","4068f0880b399410602d694b3cc711c8a8f4727e@steven676.net","Move recovery_emmc_protect.sh script under recovery/\n\nChange-Id: I47cdbb666c233693b326652f826b54fb510384ed","Steven Luo",true],["5955530ebd016fdd6ddb39915cfdcffd4210d35e","4068f0880b399410602d694b3cc711c8a8f4727e@steven676.net","Support extending postrecoveryboot.sh via scripts on /boot\n\nThis allows special-purpose script-driven recovery images to perform\nlast-minute tasks, such as copying an OTA package that needs to be able\nto unmount all filesystems to /tmp, before starting the recovery\noperation.\n\nChange-Id: I1b7f18c6fb039590cbda93a2dddb41a3d0b7173a","Steven Luo",true],["6909d69db3dafab24508ea8235e414e029c11a10","4068f0880b399410602d694b3cc711c8a8f4727e@steven676.net","Handle the bootloader control block properly\n\nThe BCB is not just a flag -- it's a data structure laid out as follows\n(bootable/recovery/bootloader.h):\n\nstruct bootloader_message {\n    char command[32];\n    char status[32];\n    char recovery[1024];\n};\n\nUpdate the BCB as such instead of on an ad-hoc basis; once we do that,\nwe can allow the recovery to manipulate the BCB directly, which allows\nautomatic resumption of recovery tasks interrupted by a crash or power\nfailure.\n\nChange-Id: Ib35cecad311faba889c5954288fd091efef73a7a","Steven Luo",true],["7492fffa85454afe79291ce97dabbc13409fc057","4068f0880b399410602d694b3cc711c8a8f4727e@steven676.net","recovery: add support for command files in /boot\n\nAndroid recoveries accept a list of commands to perform on startup in\n/cache/recovery/command; while this is a good location for an installed\nsystem to communicate with a recovery, it doesn't work for creating\nspecial-purpose script-driven recovery images (for initial install or\nrepartitioning, for example).\n\nAs a solution, introduce a command file in /boot (we have to be able to\nship files in /boot to have a recovery image anyway, so this is a\nnatural place to put it), and copy the arguments from that file to the\nbootloader control block on recovery startup so that they'll be picked\nup.\n\nChange-Id: Ic06850d02ef7d6f59f6ae99f3d0eef79b82e1857","Steven Luo",true]],"size":7,"ref":"refs/heads/cm-11.0","head":"7492fffa85454afe79291ce97dabbc13409fc057"}