The Android Boot Process

The quotation stated above is one hundred percent apt. Android, by the looks of it, seems to be a simplistic Operating System. However, in contrast, the processes and functions that add up to the OS a majority of the smartphone consumer uses are a lot more complex.

The boot process, for starters, is nothing but a bunch of fancy images and animations for the end user. This post aims at breaking the boot process down for those very end users. And I promise a thorough read is all you need to understand the process. Nothing is too complicated if explained the right way.

A skeleton of the basic process

Boot ROM -> Bootloader -> Kernel -> init -> Zygote -> Dalvik VM -> System servers -> Managers

The above happens to be the core process of the Android boot. It certainly looks a lot more complicated than the simple hold of a power button. Let’s explore each, and every step inclusive of parallel operations ( if any, ) henceforth.

Boot ROM

The code responsible for the section named “Boot ROM” is executed as soon as the power button is held. The point of origin for the code happens to be a predefined, hardcoded location. The code loads the bootloader into the RAM and executes itself.

Bootloader

The bootloader is as small a component of the Android system, as heavy the term is. You might have heard of an OEM or manufacturer placing certain limitations and rules — this is exactly where all those “rules” are stored. The process termed as “bootloader” in the skeleton encompasses two stages:

Stage one — the detection of RAM. The bootloader detects the RAM and executes an application required to initiate the second step.

Step two — setting everything up. The bootloader now proceeds to set the network, low-level memory management, and security options up.

This step is critical for the execution of the kernel. The bootloader located at /bootable/bootloader/legacy/ contains two very important files, namely, init.s and main.c

The init.s file basically initializes stacks, zeroes and BSS segments. It then proceeds to initialize call_main() in main.c. The main.c file initializes the hardware, specifically, the clock, console, and keyboard while creating Linux tags parallelly.

We will try not to dive into the extreme specifics. No one wants to read a post with a word count of 1000 words explaining something technical in “brief.” This is where dropping a comment helps.

The Kernel

The process of initialization for the Android kernel mimics the initialization of the Linux kernel. As the kernel executes, it sets the cache, protected memory up and schedules different load drivers. When the process of setting everything up and scheduling the drivers successfully comes to an end, the kernel looks for init in the system files.

Init process

The init process is considered to be quite a significant step. Not only are directories or partitions like /sys and /dev mounted, the init.rc script is also initiated. The init process is located at /init whereas the init.rc script is located at /rootdir

Zygote and Dalvik

The Zygote is a VM process that starts as the system boots. It enables code sharing across the Dalvik VM which helps in the achievement of minimal startup time. The Zygote also ensures a lower memory footprint, keeping the Dalvik VM from consuming insane amounts of memory. Moreover, it initializes core library classes.

The Zygote loading process’ skeleton looks exactly like the one we’ve outlined:Load Zygote init class -> registerZygoteSocket() -> preloadClasses() -> preloadResources() -> user's eyes staring at the magnificient boot animation

System service

The Zygote now forks a new process to have the process outlined below initiated, processed and executed.

Starting power manager -> Creating the Activity Manager -> Starting telephony registry -> Starting package manager -> Setting the activity manager service as a system process -> Starting context manager -> Starting system contact providers -> Starting battery service -> Starting alarm manage -> Starting -> sensor service -> Starting window manager -> Starting Bluetooth service -> Starting mount service -> Starting status bar service -> Starting hardware service -> Starting NetStat service -> Starting connectivity service -> Starting Notification Manager -> Starting DeviceStorageMonitor service -> Starting Location Manager -> Starting Search Service -> Starting Clipboard Service -> Starting checking service -> Starting Wallpaper service -> Starting Audio Service -> Starting HeadsetObserver -> Starting AdbSettingsObserver -> A high-five to whoever read the whole thing! Thank you

Photo by portalgda on Foter.com / CC BY-NC-SA

Analysis

Now that bootup has successfully ended, and the services are up and running, you may want to learn the art of creating logs

Developers, you’re welcome

Use adb to get the events from the boot process log cat. Enter the commands given below in the respective order of the layout. Almost typed “Phoenix” there.

adb logcat -d -b events | grep “boot”

adb logcat -d | grep preload```