In this post I want to try and find out more stuff about theAndroid software framework initialises. Ilooked a little bit at the boot process. Now I really want to get abetter idea of what is actually happening with the system runtime.

The important processes in the system appear to be zygote(which is theapp_process binary), and runtime.These are both started up by theinit process. The followingfragment of init.rc is relevant. It is important to note thatthese services have theautostart 1 attribute, indicating theyare restarted if they quit.

zygote {        exec /system/bin/app_process        args {            0 -Xzygote            1 /system/bin            2 --zygote        }        autostart 1    }    runtime {        exec /system/bin/runtime        autostart 1    }

If we go and kill either the zygote, orruntime process something interesting happens. Firstlythe other process seems to kill itself, and then the whole systemseems to restart.

Changing the ramdisk image

I want to get a bit more control of what things are starting up when.To do this I need to modify theinit.rc file. To do thisI first extracted the the ramdisk to the fileystem so that I can modifyit (gnucpio -iz -F ramdisk.img).

After this I simply commented out the line from init.rc. Thenwe can recreate it: (gnucpio -i -t -F ../ramdisk.img | gnucpio -o -H newc -O ../rootfs.img).

Note if you are using Mac OS X, you will need to download and installgnucpio, becuase the built-in cpio doesn't supportnewc.

We can then use the emulator -ramdisk option to loadour new ramdisk.

Manual startup

Now we can start things up manually. First we start up the zygote process.As # app_process -Xzygote /system/bin --zygote. When we do that thereis no output either on the console, or on the LCD. Next we start the runtime process( # runtime), and now things start to happen!

Once both processes start we get the cylon image, and we also end upwith some console output:

Prepping: /system/app/AlarmProvider.apk:/system/app/Browser.apk:/system/app/Calendar.apk:/system/app/Camera.apk:/system/app/Contacts.apk:/system/app/Development.apk:/system/app/GDataFeedsProvider.apk:/system/app/Gmail.apk:/system/app/GmailProvider.apk:/system/app/GoogleApps.apk:/system/app/GoogleAppsProvider.apk:/system/app/Home.apk:/system/app/ImProvider.apk:/system/app/Maps.apk:/system/app/MediaPickerActivity.apk:/system/app/MediaProvider.apk:/system/app/Phone.apk:/system/app/PimProvider.apk:/system/app/ApiDemos.apk:/system/app/SettingsProvider.apk:/system/app/Sms.apk:/system/app/SyncProvider.apk:/system/app/TelephonyProvider.apk:/system/app/XmppService.apk:/system/app/YouTube.apkFile not found: /system/app/AlarmProvider.apkFile not found: /system/app/Calendar.apkFile not found: /system/app/Camera.apkFile not found: /system/app/GDataFeedsProvider.apkFile not found: /system/app/Gmail.apkFile not found: /system/app/GmailProvider.apkFile not found: /system/app/MediaPickerActivity.apkFile not found: /system/app/PimProvider.apkFile not found: /system/app/ApiDemos.apkFile not found: /system/app/Sms.apkFile not found: /system/app/SyncProvider.apkFile not found: /system/app/YouTube.apk Prep complete

It might give some clue of which Google applications will be available in the future. :)

The output from runtime looks like this:

+++ post-zygote

There is also some interesting output from the kernel. Inparticular the binder_open log. We can look at these inmore detail later.

binder_open(c086f300 c0832160) (pid 462) got c5cea000binder_open(c086f300 c095ec40) (pid 475) got c4e8b000binder_open(c086f300 c095ef40) (pid 476) got c46f8000android_power: auto off timeout set to 604800 secondsDescriptor2Node failed secondary: desc=4, max=32, node=c4e8c350, weak=0binder_open(c086f300 c4008d60) (pid 513) got c473a000binder_open(c086f300 c4008760) (pid 512) got c39fc000binder_open(c086f300 c4008260) (pid 531) got c35e3000

That is about enough detail for this entry, next time I'll be usingstrace to try and get a bit more information about theseprocesses.