[Atrix 4G Android Development] NFHimself:
Some attempt at docs. :)

Root/Unroot

I am using Gingerbreak to gain a temp root, which then runs a root.sh script with elevated privileges to remount /system and copy su and sush to /system/bin, link in /system/xbin to su, and copy su over to /osh/sbin/frozenfish. Prior to running GingerBreak, the app brings up the system settings for memory cards, so you can unmount them. This will keep you from losing the contents of your internal memory and external sdcard, the app will wait until you have unmounted both. You still have to reboot however. Be sure to click install or replace for Superuser.apk when your phone reboots, around 10 seconds after you see the home screen again.

Unroot just uninstalls Superuser.apk and and deletes the files copied above.

Early USB enumeration:

How to enter:

Hold down volume down when you first turn the phone on, it will say fast boot.

Click volume down until it says early usb enumeration mode.

Press up volume to select.

What it is:

All this boot mode does is enable the usb port so it is available for adb access.

App_Process:

What this is:

It's what starts all the androidish things happening, otherwise you have just linux running on your phone. It is located in /system/bin and is called by init in init.rc. It invokes pre-zygote, zygote, and post-zygote classes (sets of functionality related to getting all the phone services running).

Early usb mode recovery:

What this is:

This is a script in /system/bin replacing app_process. This gets activated when there is an update.sh in /cache OR if you are in early usb enumeration mode and the usb cord is plugged in. In either case, the system partition is moved to /old_system and a copy of it is running from ram, system and root are in read write mode, both sdcards are manually mounted.

So long as you are booted into early usb enumeration mode and the usb cord is plugged into your PC, the phone will wait for the plug to come out, halting the boot process. You can fix your framework-res.apk files, do whatever, and the phone won't crash. When you are done you can pull the plug and the phone will continue where it left off. The system partition is remounted read only and put back as /system, the sdcards are synced and unmounted for vold to find later on.

(Your pc will beep saying usb is disconnected, that is the script turning off usb while it is copying the system partition, it will beep again when it reconnects usb. This is to avoid being in an adb shell and things are still in the works.)

If you have an update.sh script in /cache, regardless of whether you are in early usb enumeration mode, it will go through the same process above, the script will do it's thing while the real system partition is out of the loop, and continue on automatically.

2nd-Init:

This is implemented by adding (not replacing) mount_ext3.sh in /system/bin.

This script changes the affinity of init to be single core, and hacks into it to restart init. Everything already done up to the point in init.rc where mount_ext3.sh is located is not undone, there is a replacement init.rc stored in /system/etc/rootfs that leaves out the bits that were already done and disables some reboot detection. In my implementation of this, I make the phone insecure by replacing the root default.prop file, it gives root access to adb, and causes eclipse to freak out in it's console tab. :)

Deodex/Odex:

This app attempts to download a file to internal mem from my dropbox account named system_$version.tar.gz, where $version is the contents of your ro.build.id. This file contains the deodexed app and framework files, as well as some tweaks for build.prop in /system. It may also contain a bootanimation and apns list if you are running on Bell and have a foreign firmware loaded. A backup of the odexed files is also created in internal mem, as well as contents of any modified folders. The downloading is done right away, the deodexing is done via update.sh script on the next boot. Same process applies for reversing things.

Full Phone Backup/Restore:

This has nothing to do with nandroid or backing up personal settings.

The contents of /dev/block/mmcblk0p1 though mmcblk0p14, and mmcblk0p17 are dumped to internal mem in a folder called backup_$version, where $version is your ro.build.id. The data partition (mmcblk0p16) is 2GB, I create a tarball of that instead of a straight dump, you can do a factory reset to get that back to stock if anything goes wrong. The cache partition (mmcblk0p15) is just temp space, I leave that out.

To restore the process is reversed, it is implemented as update.sh in /cache for next boot. In this case the script reboots the phone and deletes itself. You can't replace the contents of system by essentially flashing it, and keep it's mount going.