Android initialization process

Android startup process:
(1) Start the basic Linux system at startup, then boot and load the Linux Kernel and start the initialization process.
(2) Start the Linux daemon (deamons:
Start the USB daemon (usbd) to manage USB connections,
Start the Android Debug Bridge daemon (adbd) to manage the adb connection,
Start the Debug daemon (debugadh) to manage debugging process requests (including memory conversion ),
Start the wireless interface daemon (rild) to manage Wireless Communication
(3) Start the Linux daemon and the Zygote process. The startup content of the process is as follows:
Initialize a Davlik VM instance
Classes and listeners required for loading Socket requests
Create virtual machine instances to manage application processes
(4) Next, initialize the runtime process, which must be processed to start:
Initialize Service Manager
Register the Service Manager as the Context manager of the default Binder service.
(5) After runtime initialization, send a request to Zygote to start the service. Zygote will create a virtual machine instance for the System Service and start the system service.
(6) then, the system service will start native system services, including Surface Flinger and Audio Flinger. These local services will be registered to the Service Manager.
(7) The native system service starts the Android Management Service, and the Android Management Service will be registered to the Service Manager.
(8) after the system loads all the services, it will be in the waiting state. Wait for the application to run, and each application will start a separate process.

Android applications call underlying hardware and services in three ways ):
(1) App-> Runtime Service-> Lib
The application calls the Runtime Service of the application framework through Binder IPC at the application layer, binds the native Service of the Runtime Library through JNI, and dynamically loads the Hal library, then, the Linux kernel-layer Lernel Driver is called.
(2) App-> Runtime Service-> Native Service-> Lib
Compared with the first one, the Runtime Service only binds the native Service through JNI, and then calls the native Service through the IPC Mechanism for dynamic loading.
(3) App-> Runtime Service-> Native Deamon-> Lib
Compared with native service calls, JNI is used to bind native services directly, and then Socket is used to call the daemon process for dynamic loading.