Android system startup process

Han Mengfei sha yue31313 Han Yafei Han_meng_fei_sha [email protected]

Android launcher icon

====

After you press the power switch, the Android device performs the following steps.

One of the words in Step2 in the picture is misspelled, boot loaeder should be boot Loader

====

First step: Power Up and system boot

When the power is pressed, the boot chip code starts to execute from a predefined place (cured in ROM). Load the bootloader into RAM and then execute.

Step Two: Boot program

The bootloader is a small program before the Android operating system starts to run. The bootloader is the first program to run, so it is specific to the motherboard and chip. Device manufacturers either use popular boot programs such as Redboot, Uboot, Qi bootloader, or develop their own boot programs, which are not part of the Android operating system. A bootloader is a place where OEMs or operators lock and restrict.

The bootstrapper executes in two stages. The first phase detects the external RAM and loads the programs that are useful for the second phase, and the second stage, the boot program sets up the network, memory, and so on. These are necessary for running the kernel, and in order to achieve a specific target, the bootstrapper can set the kernel based on configuration parameters or input data.

Android bootloader can be \bootable\bootloader\legacy\usbloader found in.
The traditional loader contains a file that needs to be explained here:

1. Init.s Initialize the stack, clear 0 BBS segment, call MAIN.C's _main () function;
2. MAIN.C Initialize the hardware (alarm, motherboard, keyboard, console) and create a Linux label.

More about the Android boot program can be learned here.

Step Three: Kernel

The Android kernel boots up in the same way as the desktop Linux kernel. When the kernel boots, set the cache, Protected Storage, schedule list, load driver. When the kernel finishes the system setup, it first looks for the "init" file in the system files and then starts the root process or the first process of the system.

Fourth Step: Init process

Init is the first process, and we can say that it is the root process or the parent process of a process. The INIT process has two responsibilities, one is to mount the directory, such as/sys,/dev,/proc, and the second is to run the init.rc script.

• The init process can be /system/core/init found at.
• init.rc files can be /system/core/rootdir/init.rc found in.
• Readme.txt can be /system/core/init/readme.txt found in.

For init.rc files, there are specific formats and rules in Android. In Android, we call the Android init language.
The Android initialization language consists of four types of declarations, actions, Commands (commands), Services (service), and options.
Action: The action is named after the command flow, and there is a trigger that determines whether the action occurs.
Grammar

12345

; HTML-script: false ] On < Trigger> < Command> < Command> < Command>

Services: The service is the program that the INIT process starts, and the INIT process restarts the service as appropriate when the service exits.
Grammar

12345

html-script: false service &lt< Span class= "Crayon-sy" >; name&gt; &lt; Pathname&gt; Span class= "Crayon-sy" >[&lt;argument&gt;]* &lt; Option&GT; &lt; Option&GT;     .. .

Options (optional)
The option is a description of the service. They affect how and when the init process starts the service.
Let's take a look at the default init.rc file. Here I only list the major events and services.
Table

Action/service	Describe
On Early-init	Set the INIT process and the priority of the child processes it creates, and set the security environment for the INIT process
On Init	Set up the global environment to create cgroup (resource control) mount points for CPU accounting
On FS	Mount MTD Partition
On Post-fs	Changing the access rights of the system directory
On Post-fs-data	Change the access permissions for the/data directory and its subdirectories
On boot	Initialization of basic network, memory management, etc.
Service ServiceManager	Start System Manager to manage all local services, such as location, audio, Shared preference, etc...
Service Zygote	Start zygote as an application process

At this stage you can see the "Android" logo on the device's screen.

Fifth Step

In Java, we know that different virtual machine instances allocate different memory for different applications. If Android apps should start as fast as possible, it consumes a lot of memory and time if the Android system launches different instances of Dalvik virtual machines for each application. Therefore, in order to overcome this problem, the Android system created "Zygote". Zygote makes it possible to share code, low memory usage, and minimal startup time for Dalvik VMs. Zygote is a virtual process, as we said in the previous step when booting the system. Zygote preloading and initializing the core library classes. These core classes are generally read-only and are part of the Android SDK or core framework. In a Java virtual machine, each instance has its own copy of the core library class file and the heap object.

Zygote Loading process

1. Load Zygoteinit class, source code:/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
2. Registerzygotesocket () registers a server socket for the zygote command connection.
3. Preloadclassed "Preloaded-classes" is a simple text file containing a series of pre-loaded classes that you can find in <android source>/frameworks/base " Preloaded-classes "file.
4. Preloadresources () Preloadresources also means local themes, layouts, and Android. Everything contained in the R file will be loaded with this method.

At this stage, you can see the start animation.

Sixth step: System Services or services

After completing the steps above, run the environment request Zygote run the system service. System services are written using both native and Java, and system services can be considered a process. The same system service is available in the Android SDK in the form of system services. The system service contains all of the systems services.

Zygote Create a new process to start the system service. You can find the source code in the "Startsystemserver" Method of the Zygoteinit class.

Core Services:

1. Start the Power Manager;
2. Create Activity Manager;
3. Initiate phone registration;
4. Start the Package manager;
5. Set the activity Management Service as a system process;
6. Launches the context Manager;
7. Start the system context Providers;
8. Start the battery service;
9. Start the timing manager;
10. Start the sensing service;
11. Start the window manager;
12. Start the Bluetooth service;
13. Start the Mount service.

Other services:

1. Start the status bar service;
2. Start the hardware service;
3. Start the network status service;
4. Start the network connection service;
5. Start the Notification Manager;
6. Start the device storage monitoring service;
7. Start the location manager;
8. Start the search service;
9. Start the Clipboard service;
10. Start the registration service;
11. Start the wallpaper service;
12. Start the audio service;
13. Start the headset monitoring;
14. Start adbsettingsobserver (process adb command).

Seventh Step: Boot complete

Once the system service runs in memory, Android completes the boot process. At this time the "action_boot_completed" starts the broadcast will be sent out.

========

The Linux kernel starts up to the Android Init process, which launches Android-related services and apps.

The START process is as shown

Android system Boot Process

=========

Android Start-up process can be divided into two stages, the first phase is the start of Linux, the second stage is the start of Android, the following we separately to understand the specific process.

The first is the Linux boot, this Part I would like to skip, nothing but Linux bootloader,kernel,driver and the like, the only thing to mention here is ServiceManager, the service Manager, This is done as a process before Android is loaded and we can see this configuration item from Init.rc:

Service Servicemanager/system/bin/servicemanager

ServiceManager is the binder's service Management daemon, the core of binder, which uses binder drivers for IPC management, and the mechanism for IPC communication, which is no longer detailed here. In the app and framework, the Servicemanager.java used by the application is the communication with the daemon through proxy.

Then the Android launcher, the next section to be described in detail. Let's just take a look at the configuration in init.rc.

Service Zygote/system/bin/app_process-xzygote/system/bin--zygote--start-system-server

That is, after Linux is started, the zygote service process is started, which is just the name: Incubator, which is the incubator for all Android applications.

Let's take a look at the app_process code, where:

Frameworks/base/cmds/app_process/app_main.cpp

The following code is in the main () function:

        if (0 = = strcmp ("--zygote", Arg)) {            bool Startsystemserver = (i < argc)?                     "Zygote"); Set_process_name ("zygote"); Runtime.start ("Com.android.internal.os.ZygoteInit", Startsystemserver);} 

from which you can trace to Androidruntime, the code is located at:

Frameworks/base/core/jni/androidruntime.cpp

The following code is in the start () function:

    /* Start the virtual machine */    0)        goto bail;     ... Env->callstaticvoidmethod (Startclass, Startmeth, strarray);

That is, the virtual machine is started and the Zygoteinit function is called with JNI.

Continue tracing to the main () function of Frameworks/base/core/java/com/android/internal/os/zygoteinit.java, with the following code:

    if (argv[1].equals ("true")) {startsystemserver ();    if (!argv[1].equals ("false")) {new runtimeexception (argv[else {runselectloopmode ();}  

The former part is in the boot system service, the latter part is a conditional judgment, but Zygote_fork_mode is assigned false, so the else branch of the Runselectloopmode () function, in this function, In fact, in a dead loop, the Zygoteconnection class is used for message processing through the socket, to fork out the new zygote, and to implement the mechanism of one virtual machine per process in the most lightweight way.

Continue to see Startsystemserver (), the code is located at:

Frameworks/base/services/java/com/android/server/systemserver.java

The native function called init1 (args) in its main () function, using the JNI mechanism, tracks to

Frameworks/base/services/jni/com_android_server_systemservice.cpp, and then to

Frameworks/base/cmds/system_server/library/system_init.cpp

The following code is in the System_init () function

    0) {        //Start the Surfaceflinger        surfaceflinger::instantiate ();    }     androidruntime* runtime = Androidruntime::getruntime ();     Logi ("System server:starting Android services./n");     Runtime->callstatic ("Init2");  

This completes the instantiation of the Surfaceflinger and then invokes the Systemserver init2 () function using the runtime's Callstatic () function, which is located at:

Frameworks/base/services/java/com/android/server/systemserver.java

The code is:

public  static  final  void  init2 ( )  {slog.i (TAG,  "entered the Android system server!"); Thread thr = new serverthread (); Thr.setname (               

In this serverthread thread, we can see the familiar Android services, such as the launch of the Wallpaperservice service:

"Failure Starting Wallpaper Service", e);}

Finally, call the Systemready () function of each service to notify the system that it is ready.

At this point, the system's startup process is over

As can be seen from this, Linux init after initiating a number of daemons, the launch of the Android runtime and Zygote,zygote to start the virtual machine, system services, system services and then start the local service, and launched a number of Android services, and complete the registration work to ServiceManager, and finally the system started to complete. The process space for the system is as follows:

It can be seen that the zygote incubator implements the virtual machine at the lowest cost by copying the process in a write-time manner.

At this point, the system's startup process is over and two graphs are borrowed to illustrate the problem:

As can be seen from this, Linux init after initiating a number of daemons, the launch of the Android runtime and Zygote,zygote to start the virtual machine, system services, system services and then start the local service, and launched a number of Android services, and complete the registration work to ServiceManager, and finally the system started to complete. The process space for the system is as follows:

It can be seen that the zygote incubator implements the virtual machine at the lowest cost by copying the process in a write-time manner.

=======

Android system startup process