Android Framework Startup

Sat, 17 Nov 2007 16:45:41 +0000
tech android article

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

The important processes in the system appear to be zygote (which is the app_process binary), and runtime. These are both started up by the init process. The following fragment of init.rc is relevant. It is important to note that these services have the autostart 1 attribute, indicating they are 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, or runtime process something interesting happens. Firstly the other process seems to kill itself, and then the whole system seems 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 the init.rc file. To do this I first extracted the the ramdisk to the fileystem so that I can modify it (gnucpio -iz -F ramdisk.img).

After this I simply commented out the line from init.rc. Then we 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 install gnucpio, becuase the built-in cpio doesn't support newc.

We can then use the emulator -ramdisk option to load our 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 there is 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 up with some console output:

 Prepping: /system/app/AlarmProvider.apk:/system/app/Browser.apk:/system/app/Ca

File not found: /system/app/AlarmProvider.apk
File not found: /system/app/Calendar.apk
File not found: /system/app/Camera.apk
File not found: /system/app/GDataFeedsProvider.apk
File not found: /system/app/Gmail.apk
File not found: /system/app/GmailProvider.apk
File not found: /system/app/MediaPickerActivity.apk
File not found: /system/app/PimProvider.apk
File not found: /system/app/ApiDemos.apk
File not found: /system/app/Sms.apk
File not found: /system/app/SyncProvider.apk
File 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. In particular the binder_open log. We can look at these in more detail later.

binder_open(c086f300 c0832160) (pid 462) got c5cea000
binder_open(c086f300 c095ec40) (pid 475) got c4e8b000
binder_open(c086f300 c095ef40) (pid 476) got c46f8000
android_power: auto off timeout set to 604800 seconds
Descriptor2Node failed secondary: desc=4, max=32, node=c4e8c350, weak=0
binder_open(c086f300 c4008d60) (pid 513) got c473a000
binder_open(c086f300 c4008760) (pid 512) got c39fc000
binder_open(c086f300 c4008260) (pid 531) got c35e3000

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

blog comments powered by Disqus