The boot was broken by a recent change to build/core/Makefile. It requires a boot.img file in the out/target/product/encore directory. We use a ramdisk.img file. This adds an empty boot.img file which keeps things happy. This dummy file isn't included in the final flashable zip. We still don't do all the signing requested by cm but we do build without errors. Change-Id: Id1ee0425e034d2c4b7764fd51355469cfc971467
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
While these items of hardware are not required by the Android CDD, the fact that requesting the ACCESS_FINE_LOCATION and RECORD_AUDIO permissions implies a requirement for the hardware (unless otherwise stated in the app's manifest) makes life difficult for us unless we report the hardware present. Change-Id: Ib34d27e19c9e6f9fbce3b6042e2618debc24e6df
By default, the recovery will create a symlink for /sdcard pointing to /storage/sdcard0 and leave /emmc as an empty directory unconnected to the vold-managed volumes. For historical reasons, we use /storage/sdcard1 as our /sdcard storage; set up the /sdcard and /emmc links accordingly in postrecoveryboot.sh, which allows the CM updater to work correctly. Change-Id: Iea00ddc056c7caee591127be53fc20d2a6b12e7a
Fix two problems preventing reboot-to-recovery from working in recovery: * /rom wasn't necessarily mounted before trying to write to /rom/bcb * /system/bin was empty, so the commands in the shell script fragment weren't found Change-Id: If30a87caa62190804e78ca76370856d427e0ea5a
Legacy OTA ROM updates attempt to format and/or mount the eMMC system and boot partitions directly, instead of using the new install-location-agnostic symlinks. Users attempting to flash one of these old OTAs using a recovery installed to SD card would therefore end up modifying their eMMC, a potentially disastrous result. Prevent this from happening by bind mounting /dev/null over the eMMC system, boot, and userdata partition devices when recovery is managing an SD card install. This doesn't cause the OTA update to fail (it'll dump all of its files to the rootfs, potentially causing an out-of-memory situation), but it does prevent unexpected modification of the eMMC. If you actually need to work with the eMMC partitions from a SD card recovery, run "/sbin/recovery_emmc_protect.sh stop" to disable this protection. Change-Id: Ie1d01ef869a217dbb2d0a9f0eefc4d06f97f15fd
Particularly with the new location-agnostic recoveries, it's possible to get confused as to whether backups/restores, wipes, and (eventually) OTA flashes will affect the eMMC or SD card. Detect whether the recovery is operating on eMMC or SD on startup and display this to the user to try to avoid mixups.
While it doesn't seem to be strictly necessary for fsfinder to be complete before the recovery starts, it shouldn't hurt either, and it may prevent some potential problems in cases where recovery has been instructed to do something when it starts (flash an OTA package, for example).
To ensure that configure_vold.sh runs before vold starts, we need to use an init.rc file (postrecoveryboot.sh is run when recovery starts, after all the various services are started). We also need to edit the configure_vold.sh script to change the interpreter location for the recovery (/sbin/sh as opposed to /system/bin/sh), so we need some build system hackery as well.
On SD card installs, the first partition of the SD card is the FAT filesystem used as the boot partition. This leads vold, which searches the SD card for the first recognized partition when given a partition number of "auto", to identify /boot as the /sdcard partition. Fix this by running a script which detects SD card installs and modifies /fstab.encore to instruct vold to use the last partition on the SD card in that case.
Instead of using fixed block device names for /system and /data, let fsfinder set up links for us based on the boot location. This allows us to run unmodified from both eMMC and external SD card.
We'd eventually like to be able to install an identical software build for encore to either eMMC or external SD card and be able to boot it without any modifications. In order to do that, we'll need to be able to find the system and userdata partitions at runtime by taking into account the install location. Early userspace has no way of discovering the boot location on its own, so we modify the bootloader to pass this information on the kernel command line. fsfinder (this utility) will then parse the command line to find the boot location and set up device symlinks appropriately. To be of any use, fsfinder has to run before /system is available, so to avoid the need to ship a statically linked shell or other interpreter in early userspace, the implementation is in C and compiles to a statically linked binary.
The corresponding keymapping file in the recovery source is now default_recovery_keys.c, and recovery_ui now typically refers to a separate device-overridable file (which we want to override in the future). Change-Id: I0bde1213fcae08a61915b98da726972122dd65d2
Using YUV overlays causes rendering glitches and display sync loss when playing back certain videos, so disable their use. (It's unclear at this point whether this is a limitation of the hardware or a driver bug.) Change-Id: Ia3d8fb7aadf04feaa01cbea29962e76e224052cd
KSM scanning can keep the CPU busy during otherwise idle periods, which hurts battery life. Therefore, when KSM is in use, disable KSM scanning before the screen turns off and reenable it when the screen turns back on. Change-Id: Id577977d0b6bc7c2456334726552a6723c83593f
Our planned boot-location-agnostic software will need this information from the bootloader in order to find /system and /data. Older software will just ignore the added argument on the command line. Built from commit 54951a2 ("omap3621_evt1a: pass boot device information on kernel command line") in the encore_cyanoboot tree: https://github.com/NookieDevs/encore_cyanoboot/tree/54951a274d28f5d21f6fe9a951852264aab32172 Change-Id: I0e2b40808e366f3af553b92663bfe2051b7348a0
The implementation of the 16 bit boot animation has changed. Now we need TARGET_BOOTANIMATION_USE_RGB565 := true See: https://github.com/CyanogenMod/android_frameworks_base/blob/cm-11.0/cmds/bootanimation/Android.mk#L37 Change-Id: I8d1e3d4dbe9bcd92d6dbea5921019f888c085c90
Original suggests allowing for encore_update.zip in build directory, but test on $1 instead of $ZIPFILE bypasses this. Change-Id: I877eb78188a867f743fb347f4ac015061bd55432
CyanogenMod's settings system will blindly overwrite the value in /sys/kernel/mm/ksm/run with the value of the KSM setting exposed in performance options, which defaults to off unless we tell it otherwise. Change-Id: I9435d54216db123418218b8c98f9ad3801627c7d
Kernel Samepage Merging (KSM) periodically scans memory marked by the framework as MADV_MERGEABLE looking for duplicate pages; when it finds them, it drops the duplicates and points all users at a single copy of the page. This is particularly useful on Android, where much of the Java class data can be shared across processes. Enabling this feature on encore can save 16 MB of RAM after just a few hours of uptime. Change-Id: Ic4eed0e0e42b3170e55831e4c85373b8720ba29a
Unlike earlier releases, Android 4.4's memory management framework is swap-aware, so there is no longer an inherent barrier to using swap on Android. We can therefore make our limited memory go farther by configuring a moderate amount of zRAM-backed swap. There are two knobs being adjusted in this patch: * The amount of swap: this represents the total size of data stored in the zRAM device *before* compression. Assuming a (conservative) compression ratio of 33%, 96 MB of zRAM swap should result in no more than 64 MB of actual RAM being in use at any one time, leaving 384 MB of RAM free for other purposes. Given that other devices get along with less than 350 MB of RAM in total (after camera/codec/VRAM carveouts, before zRAM and other such techniques), this should be more than sufficient to keep the system happy. * The "swappiness" of foreground processes: this controls how willing the kernel is to push anonymous memory (pages not backed by a file) to swap. Lower values for swappiness will cause the system to try harder to free memory via other means before touching anonymous memory. In this case, Android sets a much higher swappiness value for background processes via the memory cgroup mechanism, so the effect here is to cause the kernel to strongly prefer to swap out background processes before touching foreground process memory. We can revisit both of these values later based on user experience. Change-Id: Ie8d7c47cfda435e1e087a8ec676e21d0cf135ed3
encore's been around an unusually long time, and in that time it's picked up quite a lot of cruft in BoardConfig.mk; it's time for a housecleaning. Specifically: * Remove flags for which no other references exist in the CM source tree * Reorganize remaining configuration into some semblance of a logical grouping and order