Android Runtime

This is a continuation of the post ‘The Kernel in Android’, which is part of a series of posts where I review the Android startup process.

Once the kernel’s boot process is done, the init process is started. This consists of a single user space process, which is responsible for launching a set of daemons (background processes.)
The first daemons launched are the Linux daemons which handle memory management, power management, radio startup etc. These processes are, to a large degree, not related to Android specifically and several are vendor specific drivers. We can see these processes when connected to an Android device, by using the Android Debug Bridge (ADB) tool, which is in fact also a daemon itself, to run a shell and list the processes.

We see the init process is at the top of the list.

The next thing to start are the Android specific runtime processes. We can see these further down the list of processes in the figure below. At the top we see the ServiceManager daemon, which is the service the System Server uses to register all running services on start up. The Service Manager is initialized very early on, because it must be ready to accept service registrations from the System Server. The Service Manager works as a lookup service for applications once the system is up and running. It enables applications to look up a service, for example the Activity Manager, which resides in the System Server in a separate process. The Binder then enables communication between the two, across the process boundaries. The Binder is an Inter Process Communication (IPC) framework which consists of serveral elements of which one is a kernel driver. Communication is marshalled and sent from one process down through the architecture layers to the Binder and then sent up through the layers again and unmarshalled and consumed by the receiving process. The Binder is one of the defining characteristics of the Android architecture and can be thought of as the glue that sticks everything together.

The service manager is at the very top of the list. It must start early to be ready to handle when the System Server starts service registrations.

At the very bottom of the list we notice the ADB daemon which was the service we used to display this list of processes.
Of particular note, is the Zygote process, which we see as the 5th process from the bottom. The Zygote will be the focus of the next article.