Android boot process

Understanding the boot process of an Android device will help us to understand other forensic techniques that involve interacting with the device at various levels. When an Android device is first powered on, there is a sequence of steps that are executed, helping the device to load the necessary firmware, OS, application data, and so on into memory. The following information is compiled from the original post published at https://community.nxp.com/docs/DOC-102546.

The following is the sequence of steps involved in the Android boot process:

1. Boot ROM code execution
2. The bootloader
3. The Linux kernel
4. The init process
5. Zygote and Dalvik
6. The system server

We will examine each of these steps in detail.

Boot ROM code execution

Before the device is powered on, the device CPU will be in a state where no initializations have been done. Once the Android device is powered on, execution starts with the boot ROM code. This boot ROM code is specific to the CPU the device is using. As demonstrated in the following screenshot, this phase includes two steps, A and B:

• Step A: When the boot ROM code is executed, it initializes the device hardware and tries to detect the boot media. Hence, the boot ROM code scans until it finds the boot media. This is almost similar to the BIOS function in the boot process of a computer.
• Step B: Once the boot sequence is established, the initial boot loader is copied to the internal RAM. After this, the execution shifts to the code loaded into RAM:

The bootloader

The bootloader is a small program that is executed before the operating system starts to function. Bootloaders are present in desktop computers, laptops, and mobile devices as well. In the Android boot loader, there are two stages—Initial Program Load (IPL) and Second Program Load (SPL). As shown in the following screenshot, this involves the three steps explained here:

• Step A: IPL deals with detecting and setting up the external RAM.
• Step B: Once the external RAM is available, SPL is copied into the RAM and execution is transferred to it. SPL is responsible for loading the Android operating system. It also provides access to other boot modes such as fastboot and recovery. It initiates several hardware components such as the console, display, keyboard, file systems, virtual memory, and other features.
• Step C: SPL tries to look for the Linux kernel. It will load this from boot media and will copy it to the RAM. Once the boot loader is done with this process, it transfers the execution to the kernel:

The Linux kernel

The Linux kernel is the heart of the Android operating system and is responsible for process management, memory management, and enforcing security on the device. After the kernel is loaded, it mounts the root filesystem (rootfs) and provides access to system and user data:

• Step A: When the memory management units and caches have been initialized, the system can use virtual memory and launch user space processes.
• Step B: The kernel will look in the rootfs for the init process and launch it as the initial user space process:

The init process

Init is the very first process that starts and is the root process of all other processes:

• Step A: The Init process will look for a script named init.rc. This is a script that describes the system services, filesystem, and other parameters that need to be set up:
  • init process can be found at: <android source>/system/core/init.
  • init.rc can be found at: <android source>/system/core/rootdir/init.rc.

More details about the Android file hierarchy will be covered in Chapter 3, Understanding Data Storage on Android Devices.

• Step B: The init process will parse the init script and launch the system service processes. At this stage, you will see the Android logo on the device screen:

Zygote and Dalvik

Zygote is one of the first init processes created after the device boots. It initializes the Dalvik virtual machine and tries to create multiple instances to support each Android process. As discussed in earlier sections, the Dalvik virtual machine is the virtual machine that executes Android applications written in Java.

Zygote facilitates using a shared code across the VM, hence, helping to save the memory and reduce the burden on the system. After this, applications can run by requesting new Dalvik virtual machines. Zygote registers a server socket for zygote connections and preloads certain classes and resources. This zygote loading process has been more clearly explained at https://elinux.org/Android_Zygote_Startup:

• Load ZygoteInitclass: This loads the ZygoteInit class.
  Source Code:<Android Source> /frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
• registerZygoteSocket(): This registers a server socket for zygote command connections.
• preloadClasses(): This is a simple text file containing a list of classes that need to be preloaded will be executed here. This file can be seen at this location: <Android Source>/frameworks/base.
• preloadResources(): This deals with native themes and layouts and everything that includes the android.R file will be loaded using this method:

System server

All of the core features of the device such as telephony, network, and other important functions are started by the system server, as shown in the following screenshot:

The following are some of the core services that get started in this process:

• Start Power Manager
• Create Activity Manager
• Start Telephony Registry
• Start Package Manager
• Set Activity Manager Service as System Process
• Start Context Manager
• Start System Context Providers
• Start Battery Service
• Start Alarm Manager
• Start Sensor Service
• Start Window Manager
• Start Bluetooth Service
• Start Mount Service

The system sends a broadcast action called ACTION_BOOT_COMPLETED, which informs all the dependent processes that the boot process is complete. After this, the device displays the home screen and is ready to interact with the user.

As explained earlier, several manufacturers use Android operating systems on their devices. Most of these device manufacturers customize the OS based on their hardware and other requirements. When a new version of Android is released, these device manufacturers have to port their custom software and tweaks to the latest version.