[Gen9 Android Development] trevd:
Just For Reference

https://github.com/CyanogenDefy/android_external_bootmenu

Boot menu before Android startup http://rvr.kr/android/bootmenu

There a couple of threads knocking some previous knowledge of this one.

So I figured I'd have some sleep. :laugh: and go an see some IRL friends let them know I'm still alive and just take "stock" ( no pun intended )

I'll upload a new recovery binary later on for those who wanted to hack around in that space as I fixed the Issue with the where the Power Button had stopped working. Other Recovery Binaries from different device can be loaded, Obviously, Know the Risks when playing around with unknown binaries, looking at the Recovery code it's not overtly dangerous but given just to right key combo with the correctly mounted partitions I'm sure I could brick a device fairly rapidly LOL :) ,Just sayin' . Anyways I loaded the Grouper Touch Official CWM ( Google Nexus 7 ) It looks nice, nfortunately my digitizer, doesn't digitizer but I would be an Interesting to see if insmod' the touch screen kernel modules enables the touch functionality .

Right now I'm edging back to the single ramdisk approach It does sit nicely in the context of the reset of the device. Although the Issues I highlighted need tackling I think they can be solved within the context of the Single Image.

I don't know about other developers but sometimes I can get caught up trying to cover too many edge conditions or trying to accommodate non existent user type or use cases. I don't think my mum is going to create a update script that dd's rawfs for instance :) Although prohibiting that sort of behaviour in scripts is probably worth alot of thought.

As we control the work flow of an update for example, It's a little lazy of me to expect the creator of an update to worry about maintain recovery, When Booted into recovery , the recovery binary should have the most knowledge of the system and the specifics of it's implementation and as such should be best place to manage itself and the requests of it uses, things prohibiting destructive behaviour like dd'ing rawfs through an update is one example I can think of here.

Following the "clever/defensive" recovery train of thought, I wonder if there is any device out which have those sort of migation in place or to flip it How many device will let me blindly brick them with a malicious update script. I do recall a bad recovery being responsible for bricking some samsung, I've also experience data loss myself on a motorola xoom when running out of space while a backup, so there is always danager. I think the Loop mounted partition layout gives us a safety blanket in some cases,

Again Casual Analysis and "shooting the breeze"both highlights the dangers of the space and perhaps the immaturity of recovery/os , I'll stop now tho, because this is not the place to raise general concerns about the state of android but I will be added checks and bounds to the archos recovery.

One Final Note: I'm sure it might upset some "leet hax0r rootz" user that I would impose constraints on what is a lowlevel maintenance mode.

To "It's my device, I'm Rooted I should be able to do what I want" crowd, a crowd I consider myself part of. Don't worry you can still use adb to kill your device, I'm just not going to give you the ability to do it through a user interface.

Thanks Everybody for the input and support so far, like I've mentioned Input and constructive criticism is welcome.

I'll JFMIW then! :)