controlled by BOARD_RECOVERY_HANDLES_MOUNT if it is not set
the recovery will behave like before.
this allows the recovery to handle commands like 'mount system'
it is needed for devices with two different filesystem in
recovery.fstab like RFS and EXT4 cause the regular recovery
behaviour will only generate a fstab for mounts of fstype2
and ignore the other fstype. This will also enable things like
run_program("/sbin/busybox", "mount", "/system");
on those system.
Change-Id: Ib10ffc7735a2edb8dd32be230ba885d5d2744f73
Koush is the only authoritative source for clockworkmod recoveries,
so lets try to reduce confusion as to what is "officially supported"
and what isn't...
Change-Id: Icb0f93530e69829ce69f2500b6f29df350099273
Can't back this up unless we start selectively excluding apps, which is gross.
Most apps only store interstitial files here, so it is not a huge deal.
Apps need to be able to work properly without an SD card. (Oops ROM Manager).
Revert "backup and restore of /sdcard/Android (see getExternalFilesDir)"
This reverts commit 50732e3c67.
Conflicts:
Android.mk
Change-Id: I3978c5521b4f29c4d709c3bb6a8fa7e53678a79e
The system() call implemented in bionic/libc/unistd/system.c
depends on paths.h which sets _PATH_BSHELL to "/system/bin/sh"
which is incorrect for recovery - recovery cannot
depend on /system being mounted or even sane because /system
could be corrupt when recovery is used.
We need _PATH_BSHELL to be pointing to /sbin/sh - and
therefore bootable/recovery has its own __system() call
implemented in bootable/recovery/libcrecovery that sets
_PATH_BSHELL as well as makes sure environ is used in
the call to execve.
Change-Id: I2e5fd9c259e4fd0a9aad826a297fd3233a50a7c1
For the Power menu,
frameworks/base/core/jni/android_os_Power.cpp#L180
already uses TARGET_RECOVERY_PRE_COMMAND if
TARGET_RECOVERY_PRE_COMMAND is defined in the
BoardConfig.mk for a device to make a system() call before
calling __reboot() for recovery. This commit adds
the same thing to the other places that we know we are
getting into recovery using __reboot().
Change-Id: Ifd0394fed1e87b63d80d95e0e2a049004518e27e
The Samsung Galaxy S bootloader apparently expects the kernel to be flashed to BML-managed flash - bad erase blocks will be mapped from a reservoir area.
CWM however just skips bad blocks, the usual procedure for mtd-accessed flash.
Consequently, the bootloader sees a corrupt zImage, and will usually crash when the kernel initializes.
This of course will only happen when the "boot" partition has bad blocks.
This patch was written by "eifert" and adds a tool called "bml_over_mtd" for flashing boot images which takes care of bad blocks and maps them to a reservoir area, like BML does.
Change-Id: If570717a19b879d47d70d937a0751cd85853eacd
