Android OS boot process with focus on Zygote

You just started with Android development and went through the set up new project wizard in Android Studio, pressed that glorious green play button and deployed the app to the emulator or device. The logcat window pops up and there is a bunch of logs, but every time you look closely, you see Zygote did this, Zygote did that. So what is Zygote? As defined by the Wiki, the Zygote  is

“The initial cell formed when a new organism is produced“

To get to the technical explanation it’s best to start from the beginning of boot process. As you may know, Android is based on the Linux kernel, and the device boot process usually goes like this:

Android boot process diagram

Source: zybuluo.com

Bootrom is a small piece of write-protected flash rom memory embedded inside the processor chip. It contains the very first code that is executed by the processor when it powers up or resets.

BootLoader is started by the bootrom, it’s job is to execute any specific setup before starting the Kernel, which literary means to copy os files to working memory.

Kernel will start the setup cache, protected memory, scheduling and loads drivers. When the kernel finishes the system setup, the first thing it does is look for “init” in the system files and launch the root process or the first process of the system.

init is a root process. It has two responsibilities, mount directories like /sys, /dev, /proc and runs the init.rc script that starts, among other things, native daemons like Service Manager, Media Server etc..

The Android runtime is started by init root process with the app_process command, which tells it to start Art or the Dalvik process virtual machine and to call Zygote’s main() function.

Art/Dalvik are process virtual machines. Dalvik is used on devices below Lollipop where it is replaced by Art. The biggest difference between them is that Dalvik uses JIT (just in time) and Art uses AOT (ahead of time) compilation.

Zygote is a special Android OS process that enables shared code across Dalvik/Art VM in contrast with Java VM where each instance has its own copy of core library class files and heap objects.

Efficient and fast app launch is achieved thanks to the fact that Zygote starts by preloading all classes and resources which an app may potentially need at runtime into the system’s memory. It then listens for connections on its socket for requests to start new apps. When it gets a request to start an app, it forks itself and launches the new app. It serves as a parent to all Android apps.

This forking feature comes from the Linux kernel implementation of copy-on-write resource management technique. Forking involves creating a new process that is an exact copy of the parent process. It doesn’t actually copy anything, instead it maps pages of the new process over to those of the parent process and makes copies only when the new process writes to a page. All processes started from Zygote use their own copy and only one copy of the system classes and the resources that are already loaded in the system memory.

Zygote is designed not only to respond to fork requests by new apps, but there is one process that Zygote actually starts explicitly and that is the System Server process.

System Server is the first process started by Zygote. After it starts, it lives on as an entirely separate process from its parent. It starts initializing each system service it houses and registering them with the previously started Service Manager. It also starts the Activity Manager.

Activity Manager is responsible for a new Activity thread process creation, maintenance of the Activity lifecycle and managing the Activity stack. By the end of its startup it also executes an Intent to start a Home Launcher over which it receives onClick events to start new apps from icons on the home screen.

Useful links

Android runtime PVM
Dalvik PVM
Copy on write (C.O.W)
Zygote startup