[Galaxy S II Original Android Development] Lanchon:
hey LA,

just a thought: cranking out kernels is outside of cm's jenkins must be a drag. maybe you want to consider an alternative approaches...

1) recovery only flashable zip: TWRP or CM11's recovery as a flash-to-run signed zip that users can more or less have permanently on their devices for when its needed. no kernel, just mount the ramdrive and take over user space. TWRP could require kernel tweaks, but CM11 rec shouldn't.

2) a flashable zip that does this:

-backup current kernel, with checksum ideally created from live image

-maybe create a zip to manually restore that kernel

-flash (maybe off the shelf) kernel with TWRP or CWM; just the boot.img, without touching /system

-create a open recovery script for next boot

-reboot recovery

and immediately after the capable recovery boots, the script takes over:

-check checksum and restore kernel backup if ok

-delete kernel backup and scripts

-return control to user

now user can flash whatever. it's a dirty hack but solves the usability issue.

3) my preferred solution: a separate recovery partition! this requires a change in the stock ramdrive so only you can do it. there is a recovery partition on these devices that for all i know is unused. on recovery boot, make the stock ramdrive check for condition (ie: some button not pressed, phone not being charged, light sensor not exposed to very bright light, etc) and check for correctness of data in the recovery partition, and if all is green, boot into the recovery partition.

ideally this would be done with kexec and the recovery image would be a standard kernel, but i heard you may have disabled kexec in official cm12.1.

if kexec is not possible or too much trouble, during early boot just replace the currently mounted ramdrive with the ramdrive equivalent stored in the recovery partition, and fall into it. the recovery partition could contain a full kernel (nope! ramdrive extraction sucks) or just the ramdrive image, but it's obviously simpler if it just holds an ext4 partition.

the big warning is: THERE SHOULD BE A WAY TO STOP THIS BOOT FROM HAPPENING (button, light, etc). some people have damaged phones, maybe buttons or the USB port doesn't work. they could get into an boot failure situation and be stuck there and shout that you cooked their phone.

my take on this:

-a specific button (or safer yet, either of two buttons) held down to avoid booting into the recovery partition and falling back into the standard CM recovery would be safe enough.

(my choice of button? volume down which is normally used for download mode at an earlier time)

why is a button safe enough? if they somehow get the recovery partition borked or is incompatible with a newer kernel and they ever need the official recovery they can:

-hold down the button.

-some people have a failed button, but they can use the other button if there are two options.

-if neither button works, they can boot into android and fix from there; they are root in CM.

-if android doesn't work they have odin and heimdall to fix recovery

-if the usb port is dead... oh well, fix some darn hardware in your phone! if your buttons are dead, the usb port is dead, your android dies, and you bork the recovery, then pal, you were asking for it! any phone would be screwed in a dead-end situation like that, not just the i9100. all the other phones have separate recoveries that you can bork too, and there is no backup recovery.

if you want to be extra extra really extra safe, you can implement something with the light sensor. very bright light could cancel the boot, or better yet, a specific light oscillation pattern: expose the phone to light oscillating at a certain frequency to boot into standard CM. ie: visit a certain webpage, place phone against screen, bingo!