Android system framework and several call Processes

(Excerpt from some of the chapters in a book to help you understand the architecture of the entire android system .)

1.1.1 Android system architecture
To learn more about Android, you must first learn the Android system architecture. Like the operating system, Android uses a layered architecture with clear layers. Therefore, it is not difficult to master its architecture. For the Android system architecture diagram, if you are familiar with the image and understand the architecture shown in the diagram, you can skip this section (or browse it quickly ); if this is the first time you see this image, we recommend that you read this part in detail, because the content of the entire book is based on this image. We will analyze each module in the figure in detail, so that you can truly grasp the technical details of Android.

Android is divided into five layers: Application Layer (applications), application framework layer (Application Framework), and system runtime layer (libraries and Android runtime) and Linux kernel ). Next, let's take a look at what features each layer provides for us and how to use these features.
1. Application Layer
Android will be released with the core application package. The package includes the Home Page shown in Figure 1), e-mail client, SMS/MMS Short Message program, calendar, MAP, browser, Contact Management Program, etc. All applications are written in Java by calling the APIS provided by the application framework. Of course, you can also use Java to develop Native applications through JNI and Android ndk, which can improve the efficiency of applications, but the difficulty is also greatly increased-you need to be proficient in C, C ++ and other languages, and
Android ndk provides a deep understanding of the few functions. Because Android ndk does not provide many functions, you can find it after a long time to avoid it-originally, ndk does not support a function, you can choose whether to develop Native programs using ndk based on your needs.
2. Application Framework Layer
The application framework layer provides developers with an API framework for full access to core applications. The architectural design of this application simplifies Component Reuse, any application (and any other application) you can publish your own functional modules (subject to the security restrictions of the Framework ). Similarly, this application reuse mechanism allows users to easily replace program components. Next, let's take a look at the components provided by each module of this layer, as shown in Table 1-1.

3. System runtime database layer
The system Runtime Library layer consists of the library and the android Runtime Library. The following describes the two parts respectively.
(1) Library
Android contains some C/C ++ libraries that can be used by different components in the Android system. They provide services to developers through the application framework, table 1-2 describes the functions of these core databases.

 

(2) Android Runtime Library
As shown in figure 1, the android Runtime Library is divided into the core library and the Dalvik virtual machine. The core library provides most of the functions of the core library of the Java language. Here, the core Library provides the interface for calling the underlying Library to the application framework layer through JNI. The Dalvik virtual machine is implemented to run multiple VMS at the same time. Dalvik virtual machine executes the Dalvik executable file of. Dex. The files in this format are optimized for the minimum memory usage. The Dalvik virtual machine is register-based. All classes are compiled by the Java assembler, and then converted to. Dex format by using the DX tool in the SDK and executed by the virtual machine. The Dalvik virtual machine depends on some functions of Linux, such as the thread mechanism and the underlying memory management mechanism. Every android application runs in its own process and has an independent
Dalvik Virtual Machine instance. For more information, see Android SDK toolkit and Dalvik virtual machine.
4. Linux kernel layer
Android depends on the core system services provided by the Linux 2.6 kernel, such as security, memory management, process management, network stack, and driver modules. As an abstract layer, the kernel exists between the software stack layer and the hardware layer. Android enhances the kernel in the following aspects:

At this point, our analysis of the Android system architecture has come to an end. Now you should at least understand the architecture of the entire android System and the functions of each module, in order to lay the foundation for further study. How is the Android system started? What do I need to initialize during the startup process? If you do not know (or do not fully know) The answer to these questions, do not worry, the next section will analyze the initialization operations when the Android system starts.

1.1.2 Android initialization process
The previous section analyzes the Android system architecture and gives you an in-depth understanding of the Android system. However, the android system itself is very large. Before analyzing the specific functions of each module, it is necessary to analyze the startup process. We need to know which initialization operations should be performed when such a large system is started. When the Android system starts, it first starts the basic Linux system, then guides the loading of Linux kernel and starts the initialization process (init), as shown in 1-1.

Then, start the Linux daemons ). In this process, you must start the following content, as shown in 1-2.
Start the USB daemon (usbd) to manage the USB connection.
Start the android debug bridge daemon (adbd) to manage the ADB connection.
Run the debug daemon (debugadh) to manage the debugging process requests (including memory conversion and so on ).
Initiate the wireless interface daemon (rild) to manage wireless communication.

Start the zygote process while starting the Linux daemon, as shown in figure 1-3. It mainly includes the following content that needs to be started and registered:
Initialize a Dalvik Virtual Machine instance.
Classes and listeners required for loading socket requests.
Processes that manage applications by creating Virtual Machine instances.

Next, you need to initialize the runtime process. The initialization process is 1-4. In this process, you need to handle the following operations:
Initialize the Service Manager.
Register the Service Manager as the context manager of the default binder service.

After the runtime process is initialized, the runtime process sends a request to zygote to start the system service. At this time, zygote will create a virtual machine instance for the system service process and start the system service, 1-5.

Then, the system service will start native system services, including surface flinger and audio flinger. These local system services will be registered to the Service Manager as the IPC service target, as shown in figure 1-6.

The system service starts the android Management Service, and the android Management Service is registered to the Service Manager, as shown in 1-7.

Finally, after the system loads all services, it will be in the waiting state and wait for the program to run. However, each application starts a separate process. As shown in figure 1-8, the system starts a home process and a contacts process. So how do processes interact? This requires the IPC Mechanism, which will be detailed later.

By now, the entire startup process of the system is over. You can run the application on it. You should also have a deep understanding of every step of the android startup process. In fact, this startup process is to load and register it to the application framework layer step by step from the underlying Linux kernel layer in the android architecture diagram, and finally run our own applications on the application layer. So what is the relationship between different levels? How does an application call the underlying core service at the top? The next section analyzes the relationships between different layers.

1.1.3 relationship between different levels
The previous section describes the Startup Process of the Android system. This section describes how Android applications call the underlying hardware and services based on hierarchies. If you do not have in-depth understanding of the content in the previous section, you can go back and read it carefully so that you can better understand the content in this section. Okay. I believe you are ready. Let's get started. Applications running on Android are implemented in three ways:
‰ App → runtime service → lib
‰ App → runtime service → native service → lib
‰ App → runtime service → native daemon → lib
The following three methods are analyzed separately. We will use a flowchart to show them.
The flowchart 1-9 corresponding to the app → runtime service → lib method is shown.

From Figure 1-9, we can see that on the Android platform, the application first calls the runtime service of the application framework layer through the binder IPC at the application layer, then, use JNI to bind the native service in the running library, dynamically load the Hal library, and then call the kernel driver at the Linux kernel layer. For better understanding, we use a location manager to analyze the process, as shown in 1-10.

The above is the call process of the first method. Next, let's look at how the second method (APP → runtime service → native service → Lib) is called. This method is usually used by Android native services. Let's take a look at the call flowchart, as shown in 1-11.

Figure 1-11 shows the call process of the android native service. We can see that, compared with the first method, there is only one more process of calling the native service through the IPC Mechanism and performing dynamic loading. Therefore, we will not repeat it here, but we will give an example of audio, as shown in 1-12.

As shown in figure 1-12, the application calls the mediaplayer at the application framework layer, and then calls the mediaplaye at the system Runtime Library layer. Mediaplaye calls the media framework and audioflinger respectively, then calls the specified library (libaudio. So) through audioflinger, and finally calls the kernel driver. Next let's take a look at the last method "app → runtime service → native daemon → lib", as shown in 1-13. This method is usually used for daemon connection.

As shown in figure 1-13, this method is simpler than calling native services. It directly binds native services through JNI and then uses sockets to call the daemon process for dynamic loading. The following is a simple example. Telephony Manager is called as a native daemon. The process is 1-14.

The call process is very simple. I believe that figure 1-14 is clear enough.
1.1.4 Android system development (transplantation) and application development
Through the previous study, we learned that android is a huge and complete system. What development work can we do based on Android? What is the difference between each development task? What are the differences between technologies that need to be mastered in different development work? After learning the content of this section, you will know how to use android to develop your desired products. Because Android is an open-source operating system, the following two development methods are available:
Android system development (transplantation)
‰ Android Application Development
1. Android system development (porting)
Android system development (transplantation) is the underlying development work. It mainly improves and migrates the Android system to other hardware platforms, therefore, you must master the Linux kernel layer and system Runtime Library layer in the Android system architecture, as shown in figure 1-15. Android system development mainly involves libraries and Android runtime. Generally, C/C ++ code is written locally, and the calling interface is provided through JNI to the upstream layer, it mainly provides services for application development. The Android system porting mainly involves the hardware abstraction layer and the Linux kernel layer. The main task of porting the driver to different hardware so that it can run Android perfectly
System. These drivers mainly include device drivers and Android drivers.

Whether it is system development or system transplantation, the source code of Android is directly operated at the underlying layer. Therefore, before development, we must first prepare the source code of Android. The next section describes how to obtain and compile the andorid source code and the structure of the android source code.
2. Android Application Development
Android Application development mainly writes various applications based on the APIS provided by the Android system. The APIs used belong to the Android Application Framework layer, as shown in figure 1-16. If the Android system does not provide some APIs, you can only write C/C ++ code at the underlying layer of the Android system to develop these APIs and provide interfaces to the Android Application Framework layer. However, I do not recommend this because it may cause incompatibility between your application and Other Android systems.

The applications we developed are running at the same level as those at the application layer. Therefore, we remind you that you must follow the android API framework rules when developing applications, to avoid incompatibility between developed applications. In addition, application development belongs to upper-layer development and does not need to be exposed to the underlying C/C ++ code. Therefore, before development, we only need to prepare the android SDK and simulator (of course, you may also need an IDE, and eclipse is recommended ). Finally, the android SDK can be obtained by compiling the source code or download the compiled SDK from the official website of Android. The following describes how to obtain the source code by compiling the source code.
Android SDK, as well as the SDK structure and development kit.