[Gen9 Android Development] trevd:
Thanks, No Pun Intended eh? ;) I see the word rooting and I just think android :D

WARNING: THIS IS LONG AND HEAVY ON TECHNICAL DETAILS

Anyway down to business and Good News!!

I've got over my earlier concerns regarding maintaining the integrity of the boot partition between updates when using a single initramfs for both Android and Recovery modes. I think I was over complicating the problem and once again looking at use cases that don't exist. So I'm confident we can have a workable solution using this single initramfs / persistent property approach.

NOTE: The following is explained in the context booting a JellyBean AOSP Rom - For more information on the Android Init Process see Android Init Language Section

All Android devices by their nature have device specific settings in their init.rc files and the G9 is no different. The way it's going to work is a follows.

The rootfs is contained in the initramfs.cpio.gz ( or lzo ) , I've built a kernel that supports both as the AOSP Builds a gzipped ramdisk

Init Script Structure

/init.rc
/init.usb.rc
/init.trace.rc
/init.archos-common.rc
/init.recovery.rc

init.rc, init.usb.rc, init.trace.rc are standard JellyBean init files. I've taken a long hard look at what archos are doing with the files in /system/etc/init on their standard roms and I think that the differences between devices is minimal a can be handled in one common file ( init.archos-common.rc ) that takes of advantage of android "on property" init action. Finally init.recovery.rc is where the bootmode switching is handled, it's contents are as follows

## Removed Disabled to start recovery automatically
## CWM Recovery disabled as we are boot full android. It should be possible to soft boot into recovery
## if android is stopped properly.
service recovery /sbin/recovery
disabled

### The reboot_into service is a new service which manages makes sure we reboot into
### sde mode
service reboot_into /sbin/reboot_into -s sde
class core
oneshot

## For archos testing run adb as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1

on property:persist.sys.bootmode=*
setprop sys.bootmode ${persist.sys.bootmode}

on property:sys.bootmode=recovery
mkdir /sdcard
mkdir /etc
symlink /sbin/recovery.fstab /etc/recovery.fstab
start reboot_into
start recovery

on property:sys.bootmode=android
symlink /storage/sdcard0 /sdcard
symlink /system/etc /etc
class_start core
class_start main

I've also added a line to the /default.prop which covers first boot where no persist.sys.bootmode property exists yet.

persist.sys.bootmode=recovery

Updating Files in the Initramfs through Update zip

As most roms at most will want to update init.rc or init.archos-common.rc in the boot partition this can be simply managed as we have to tools to update the initramfs ( kd_flasher ). Although all flashable ( Edify Scripted ) update zips come with their own standalone update-binary, which from what I can gather is a mini-recovery type affair, It must pass through and be validated by code containing in the recovery binary which gives us a chance to catch anything that may destroy the recovery functionality. I also think It would be smart to remove the need for the rom creator to distribute the init.recovery.rc as It can be inserted into any new init.rc by the update process.

I'll caveat the above by saying I'm no expert in the ways Edify so If I've missed something or you think I've got it totally wrong then let me know any input is welcome on this as I'm not going to be the one using it.

First Boot

Like I mentioned, when you first flash this initramfs the default.prop bootmode is used. My plan moving forward is to have an automated setup to create the empty ext4 images. Then to flash an update.zip containing the system files. Not only will this provide a good sanity check of the system but reduce the space and time required to complete the process.

Moving Forward

Of course a lot of the above functionality is VapourWare at the moment and there is more work to do, to take It forward I'll package it all in with This Rom so ( brave ) folks can get an idea of exactly what I'm talking about, I expect to have something during the next week.

Notes For BackPorting Existing Archos Stock Roms

As I seem to bang on about, Archos have pretty much a include separate standalone embedded linux distro which they have intertwined with the Android system. these are the files contained in /bin /lib /usr on the Stock archos roms. This means if you take the /system directory out of the archos firmware you are left with around 38MB in your root, Obviously this doesn't fit in a initramfs.

There are 2 obvious solutions if anyone wishes to have a crack at restructuring a Stock Rom.

1. Remove the embedded linux entirely.

To do this any binaries used by Android Services etc that are outside of the /system directory would need to be recompiled against bionic.

From looking at lastest Firmware these are thing like usb_modeswitch smbd etc, the source code for most if not all of these file is available.

Archos Also seemed to have dropped their avos service on the latest firmware which takes a closed source binary out of the picture.

2. Move the /usr /bin /lib and symlink into the root

During Earlier tests I used the method and moved the root directories to /system/buildroot/* then symlink back. this is obviously the quickest simplest approach and does seem to work ok.

There are further considerations such as the /init binary which archos use is heavily modified to look for it's init file in /system/etc/init/.

You may run into trouble maintain the bootmode property setting as this is done in the android_reboot function of /system/lib/libcutils.so and I don't if recompiling only that library will play nice with the reset of the system. I suppose an alternative method would be to port archos functionality into a clean AOSP rom but then surely that would be doing their Job for them :).

If anyone wants further details on backporting or archos specialness either drop me a pm or ask in this thread.

Phew.... That's a long one, At least it's coherent today! ( I hope ) You see folks, I'm not mental LOL :D