How to Support Epic CM

UPDATE Feb 1st, 2012:
Please read the Status Update.

Issue with Low memory killer and kswapd0

UPDATE: This was fixed in CM9 alpha2.  We think...

CM9 longterm testing is showing Android and kswapd0 (part of the linux kernel) are fighting over the small amout of space available.  Android appears to be caching some apps to use most of the available space however when an App opens the sudden lack of free ram causes kswapd0 to become very active and and eat a lot of cpu for seemingly no purpose till android releases a small amount of ram to pacify kswapd0.

I backed out https://github.com/CyanogenMod/android_kernel_samsung_victory/commit/9f470cb2eda8f9c5316c2772bf0c2d5c53d8b138 which was a lowmemkiller change and it appears to have been the cause of the issue.  I am continuing to monitor the memory and will update with any further changes.  Is there threshold changes that need to be made?

How to make Flashable .zip and .apk's

<mkasick> a flashable zip has to have "META-INF/com/google/android/update-binary" which is invoked by recovery
<mkasick> the usual update-binary is compiled from AOSP or CM sources, if you follow the source.android.com directions for obtaining AOSP sources, you can make it with "make out/target/product/generic/system/bin/updater; cp -a out/target/product/generic/system/bin/updater update-binary"
<mkasick> that update-binary also requires "META-INF/com/google/android/updater-script" in the zip, which in recent Android is "edify" format, there's a bunch of tutorials on writing edify updater-scripts
<mkasick> some update.zips are signed, as stock/AOSP recovery checks the signature and verifies the zip contents before installing, although CWM is modified to disable the signature check by default
<mkasick> Samsung stock recovery uses a signing key we don't know, but AOSP defaults to a well-known key "testkey"
<mkasick> the public keys is actually contained in /res/keys of a recovery initramfs, so some custom kernels use the testkey public key instead so they can flash testkey-signed zips
<mkasick> zips are signed using signapk.jar, which can also be made from AOSP sources ("make out/host/linux-x86/framework/signapk.jar")
<mkasick> http://www.club.cc.cmu.edu/~mkasick/android/tools/signapk.tar.gz is a compiled version I built
<mkasick> that archive also includes the testkey keypair and a README that demonstrates how to use it to sign an update.zip
<mkasick> particularly notable (or rather, it took me a good while to figure out) is that you have to invoke signapk.jar with "-w" to sign the "whole zip", which is required for update.zips and nothing else in Android to my knowledge
<mkasick> on packaging .apks
<mkasick> source-built apks are packaged when buiding from AOSP/CM sources, or from the Android SDK
<mkasick> it's a blackbox mechanism as far as I'm concerned
<mkasick> if you want to repackage an existing apk, apktool (https://code.google.com/p/android-apktool/) is probably the best

Multiboot Android for Debugging/Testing

This post will contain notes on setting up a multiboot environment on your Epic 4G, allowing you to boot different kernels and Android userspace "ROM's" stored on the sdcard.  This makes it faster and safer to test new builds.

<mkasick> EI22 on sdcard is just putting /system, /data, and /cache as mmcblk0p2-4 ext4-formatted partitions respectively
<mkasick> first, you'll need to flash back to EI22
<mkasick> and make a tar of /system to preserve uid and permission bits
<mkasick> "cd /system; busybox tar cf /sdcard/system.tar ." is what I use, you can run it from a root shell either in recovery (when /system is mounted) or while in Android since /system is always mounted read-only
<mkasick> and keep that guy around since it's very handy to have a properly-permissioned /system dump (which ironically, I don't have, at least not unmodified)
<mkasick> the instructions for formatting the sdcard are here: http://forum.xda-developers.com/showpost.php?p=19460677&postcount=25
<mkasick> the one difference is you'll have to use "mkfs.ext4 -O ^has_journal /dev/sdb2" (or device equivalent) to format the system partition for EI22 since it's large enough that the 8 MB journal takes too much space
<mkasick> or you can make the partition larger, but the journal doesn't matter sine it's never mounted rw after the first write
<mkasick> warren, http://www.club.cc.cmu.edu/~mkasick/android/sdrom/kernel-GB-sdrom.tar.gz and http://www.club.cc.cmu.edu/~mkasick/android/sdrom/kernel-GB-sdrom-patches.tar.gz
<mkasick> the first is an EI22 custom kernel that runs EI22 installed on SD, the second are the patches against the kernel and a README with build instructions and how to prep the SD card
<mkasick> the patches are fairly minimal, it's a few to "better support" being kexec'd, and the userdebug patch which enables "adb root" to run adbd as root (if you don't already have a rooted /system), and the testkey public key if you use _its_ recovery to flash update.zips
<mkasick> which is unlikely, and you'd need to kexec into its recovery, but it's there
<mkasick> the kernel has partial BML support, it uses Samsung's param.ko and mounts /mnt/.lfs, but doesn't include rfs or attempts to mount /system,/data,/cache from OneNAND, so it will work fine on MTD devices.  

• EI22 as root, tar the contents of /system in at tarball in order to preserve permissions.

mount -t vfat /dev/block/mmcblk0p1 /sdcard
cat /sdcard/busybox-armv6l > /tmp/busybox

chmod 755 /tmp/busybox

cd /system

rm etc/install-recovery.sh recovery-from-boot.p

mount -ro remount /dev/block/stl9 /system

/tmp/busybox tar cvf /sdcard/system.tar .

umount /sdcard

sync

• Install CWM5 BML (for 3 finger boot recovery)
• Install CM7 MTD.
• Install CWM5 BML again.  This kernel supports kexec, so you can most easily boot into alternate ROM's from here.
• Use this in CWM5 BML to reboot into CWM5 MTD if you want to modify your CM7 installation.
• Something like this from CWM5 BML will allow you to boot into alternate ROM's.

Kernel Console on Epic 4G

• Serial Debugger
  We have not found a way to print kernel console messages to the screen.  In order to capture kernel messages, a serial debugger rig can be connected to the USB port.  Advantage of the debugger vs the screen is that you can capture the logs for offline analysis. [thread1] [thread2]
• ram_console <mkasick> the way I do ram_console is I kexec the kernel I want to test, it fails, reboots automatically to the working recovery kernel, and I run "adb shell cat /proc/last_kmsg" to pull the boot-time log of the failed kernel and see what went wrong