Talk about what happens when the Android system starts.

Android system complete boot process, from the system level angle can be divided into Linux system layer, Android system service layer, zygote process model three stages, from boot to start home launcher complete the specific task details can be divided into seven steps, Here's a detailed explanation of the complete initialization process for Android systems.

First, start bootloader

The Android system is based on the Linux operating system, so its initial boot process is the same as Linux. When the device is powered on and executes the bootloader boot loader first, bootloader is a small program that runs before the operating system kernel runs. This applet initializes the hardware device, establishes the memory space map, and directs the hardware and software environment of the system into the appropriate state to prepare the correct operating environment for the final call to the operating system kernel.

When the Linux system starts:
1) First load the BIOS hardware information and obtain the code of the first boot device
2) Read the boot loader (LILO, GRUB, etc.) of the first boot device's MBR.
3) core information of the core operating system is loaded, the core begins to decompress, and attempts to drive all hardware devices.
............

In embedded systems, there is usually no firmware program like BIOS, so the entire system load task is done through bootloader.

Second,Load System kernel

A Linux kernel image typically consists of two parts of code, namely real-mode code and protected-mode code. When bootloader loads the kernel image into the code snippet memory, it places the real-mode code and the protected-mode code into different locations, and then goes into the real-mode code execution, which is transferred to the protected mode code when the real-mode code is completed.

The concept of real mode and protected mode again does not explain too much, and readers can consult their own data.

Third, start the init process

When the kernel is loaded, the init daemon is started first, which is the first user-level process initiated by the kernel, and its process number is always 1. After the init process starts, it is also responsible for initiating other important daemon processes, including:
USBD process (USB Daemon): USB connection background process, responsible for managing USB connection.
ADBD process (Android Debug Bridge Daemon): ADB connects to the background process and is responsible for managing ADB connections.
Debuggerd process (Debugger Daemon): Debugger Daemon, responsible for managing debug requests and debugging procedures.
Rild process (Radio Interface layer Daemon): Wireless Interface Layer Daemon, responsible for managing wireless communication services.

Iv. initiating the zygote process

After the init process and some important daemons start to complete, the system starts the zygote process. After the Zygote process starts, it initializes a Dalvik VM instance, loads the resource and system share library for it, and opens the socket listener service, and when it receives a request to create a Dalvik VM instance, it uses the cow (copy on write) technology to maximize its reuse. Generates a new Dalvik VM instance. Dalvik VM Instance creation method is based on the fork principle of the Linux system.

In fact, I personally understand that the zygote process is equivalent to the fork process in a Linux system. It is possible to hatch Dalvik VM instances While the system is running, when it receives a request to create a virtual machine. The zygote process hatches the Dalvik VM instance process as shown in:

<ignore_js_op>

Figure 1 Zygote process hatching Dalvik VM instance process

V. Start the runtime process

After the zygote process starts, the INIT process starts the runtime process. The runtime process first initializes the Service manager and registers it as the default context manager for the binding service (Binder services), which is responsible for the registration and lookup of the binding service. The runtime process then sends a request to the zygote process to start the system service, and after the zygote process receives the request, it "hatches" a new Dalvik VM instance and starts the system service process. The startup process of the runtime process is as follows:

<ignore_js_op>

Figure 2 Runtime process start flowchart

Vi. starting local Services

The system service starts with two local services (native services written by C or C + +), Surface Flinger and audio Flinger, which are registered with the Service Manager as an IPC service object. So that they can be easily found when they are needed. Systemservice will then launch some Android system management services, including hardware services and system framework core platform services, and register them as IPC service objects. The startup process for the local service process is as follows:

<ignore_js_op>

Figure 3 Systemservice starting the Local service flowchart

Seven, Start Home Laucher

When Systemservice loads all of the system services, it means that the system is ready to send a system ready (Systemready) broadcast to all services. The Systemservice system service process starts with process 1-6 as shown. When Activitymanagerservice receives the Systemready broadcast, it sends a request to the Zygoute process to create the Dalvik virtual machine instance, and the Zygoute process is responsible for generating a new Dalvik virtual machine instance. Then Activitymanagerservice finds activity in the system that has <category Android:name = "Android.intent.category.HOME"/> Property and starts it. Activitymanagerservice also launches the contact application using the same method.

<ignore_js_op>

Figure 4 Starting the home Laucher flowchart

Talk about what happens when the Android system starts.