Understanding the android’s boot process is important if you want to know how android works, especially if you want to root an android device. The boot loader is usually the first thing that runs when the hardware is powered on. On most devices, the boot loader is manufacturer’s proprietary code that takes care of low-level hardware initialization (setup clocks, internal RAM, boot media, and so on) and provides support for loading recovery images or putting the phone into download mode. The boot loader itself is usually comprised of multiple stages, but we only consider it as a whole here.
When the boot loader has finished initializing the hardware it loads the Android kernel and initrd from the boot partition into RAM. Finally, it jumps into the kernel to let it continue the boot process. The Android kernel does all the tasks needed for the Android system to run properly on the device. For example, it will initialize memory, input/output (I/O) areas, memory protections, interrupt handlers, the CPU scheduler, device drivers, and so on. Finally, it mounts the root file system and starts the first user-space process, init.
The init process is the father of all other user-space processes. When it starts, the root file system from the initrd is still mounted read/write. The /init.rc script serves as the confi guration file for init. It specifies the actions to take while initializing the operating system’s user-space components. This includes starting some core Android services such as rild for telephony, mtpd for VPN access, and the Android Debug Bridge daemon (adbd). One of the services, Zygote, creates the Dalvik VM and starts the first Java component, System Server. Finally, other Android Framework services, such as the Telephony Manager, are started. The following shows an excerpt from the init.rc script of an LG Optimus Elite (VM696). You can find more information about the format of this file in the system/core/init/readme.txt file from the Android Open Source Project (AOSP) repository.
service adbd /sbin/adbd
service ril-daemon /system/bin/rild
socket rild stream 660 root radio
socket rild-debug stream 660 radio system
group radio cache inet misc audio sdcard_rw qcom_oncrpc diag
service zygote /system/bin/app_process -Xzygote
/system/bin --zygote --start-system-server
socket zygote stream 660 root system
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
onrestart restart media
onrestart restart netd
When the system boot has been completed, an Fastboot and ODIN mode event is broadcasted to all applications that have registered to receive this broadcast intent in their manifest. When this is complete, the system is considered fully booted.
Accessing Download Mode in Android Boot Process
In the boot process description, we mentioned that the boot loader usually provides support for putting the phone into download mode. This mode enables the user to update the persistent storage at a low level through a process typically called flashing. Depending on the device, flashing might be available via fastboot protocol, a proprietary protocol, or even both. For example, the Samsung Galaxy Nexus supports both the proprietary ODIN mode and fastboot.
Fastboot is the standard Android protocol for flashing full disk images to specific partitions over USB. The fastboot client utility is a command-line tool that you can obtain from the Android Software Development Kit (SDK) available at https:// developer.android.com/sdk/ or the AOSP repository.
Entering alternate modes, such as download mode, depends on the boot loader. When certain key-press combinations are held during boot, the boot loader starts download mode instead of doing the normal Android kernel boot process. The exact key-press combination varies from device to device, but you can usually easily find it online. After it’s in download mode, the device should await a host PC connection through Universal Serial Bus (USB). Image below shows the fastboot and ODIN mode screens.
When a USB connection has been established between the boot loader and the host computer, communication takes place using the device-supported download protocol. These protocols facilitate executing various tasks including flashing NAND partitions, rebooting the device, downloading and executing an alternate kernel image, and so on.