Zygote in Android

when an application is launched , the core process for the application is forked from Zygote. Zygote has all the core libraries and hence all applications share these libraries from Zygote.

Zygote is also used to share the system drawables with all the apps.
This allows the system to load the bitmaps for buttons only once for
instance.

Zygote System Process

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
lendar.apk:/system/app/Camera.apk:/system/app/Contacts.apk:/system/app/Developm
ent.apk:/system/app/GDataFeedsProvider.apk:/system/app/Gmail.apk:/system/app/Gm
ailProvider.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:/s
ystem/app/PimProvider.apk:/system/app/ApiDemos.apk:/system/app/SettingsProvider
.apk:/system/app/Sms.apk:/system/app/SyncProvider.apk:/system/app/TelephonyProv
ider.apk:/system/app/XmppService.apk:/system/app/YouTube.apk

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