Structure Analysis of Android telephony framework

The framework 1 involved in Android telephony is shown in.

Figure 1 Android telephony Framework Structure

Figure 1 shows some rules of the android telephony framework structure.

• Android telephony's business applications span AP and BP. AP and BP communicate with each other, in line with the basic structure of the smartphone hardware described above.
• The Android system runs on the AP, while Telephony runs on the user space on the Linux kernel.
• Android telephony also adopts a layered structure that spans three layers of Java applications, Java frameworks, and user libraries, consistent with the overall hierarchical structure of the Android operating system.
• Android telephony has three layers from top to bottom: Telephony Application, telephony framework, rIL (radio interface layer, wireless communication interface layer, mainly located in the Hal layer of the userlibraries layer. The following describes Hal in detail ).
• BP software runs on BP and is mainly responsible for actual wireless communication capability processing.

1. Hal of the system Runtime Library Layer

Hal (Hardware Abstraction Layer) has different implementation methods on Linux and Windows operating systems.

Hal in Windows is located at the bottom of the operating system. It operates physical hardware devices directly and uses Abstract interfaces to isolate specific implementations of different hardware, provides a unified interface for upper-Layer Operating Systems and device drivers to abstract hardware. In this way, when you change the hardware, you only need to write the hardware driver to implement the standard interface that complies with the Hal definition, and the upper-layer applications will not be affected, so you do not have to worry about the specific hardware.

Hal in Linux is not the same as Hal in windows. Hal is not directly operating on the underlying hardware of the operating system. Rather, Hal is located on the core layer of the operating system and the driver, is a service program running in the user space.

2. Hal Structure Analysis

Through the previous study, we know that android is an open-source smartphone operating system based on Linux kernel. Therefore, we will not separately introduce the Hal structure in windows here.

To know the Hal structure, first look at the framework diagram from Hal 0.4.0 specification, 1-4 (reference from the http://people.redhat.com/davidz/hal-spec/hal-spec.html ).

Figure 2 Structure of the Hal 0.4.0 specification framework

Hal is a service program that runs on the operating system and driver in the user space. The objective is to provide a unified interface for upper-layer applications to query hardware devices. We all know that abstraction is to isolate changes. What can Hal bring to us? First, with the Hal interface, you can start application development in advance without worrying about the hardware to be implemented. Second, if the hardware manufacturer needs to change the hardware equipment, as long as the corresponding hardware driver is provided according to Hal interface specifications and standards without changing the application, Hal simplifies the hardware query logic of the application, transfer the complexity of this Part to Hal for unified processing, so that when some applications use Hal, the complexity of actual operations on different hardware can also be handed over to the database functions provided by different hardware manufacturers for processing.

In short, Hal's so-called abstraction does not provide actual hardware operations, and hardware operations are still completed by specific drivers.

3 Why did Android introduce Hal?

Some of Hal's advantages have been mentioned in the previous chapter. Let's review them here. Android introduces Hal not only for its own advantages, but also for a very important reason, this is to ensure that hardware drivers and applications developed on the Android platform based on Linux do not have to follow the GPL (General Public License) license and remain closed, which safeguards the interests of more manufacturers. We all know that Linux kernel is open-source and complies with the GPL license. According to the GPL license, any modification to the source code must be open-source to the public.

So how does Android do it? Linux Kernel and Android have different licenses. Linux kernel is a GPL license, and Android is an ASL (Apache Software License) license. The ASL license stipulates that the source code can be used at will without open source. Therefore, hardware drivers and applications built on Android can be kept closed. That is to say, as long as the key driver processing-related logic is transferred to the Android platform, only the basic communication functions are retained in linuxkernel, even if some of the Code is open source, there will be no loss for the manufacturer.

Google chose to do this and specifically modified the kernel. Some of the key processing logic that should have been included in the Linux Kernel should have been transferred to the Hal layer to achieve the goal of not having to open source.

4. Hal running structure in Android

Some Hal is implemented in the android source code, including Wi-Fi, GPS, rIL, and sensor. These codes are mainly stored in the following directories:

• Android_src/hardware/libhardware_legacy: an old Hal structure that directly calls the so dynamic link library;
• Android_src/hardware/libhardware: A New Hal structure called by stub proxy;
• Android_src/hardware/RIL: RIL (radio interface layer, wireless communication interface layer), which is the focus of this book and will be explained in detail in an independent chapter later.

In Android, what is the operating mechanism of Hal? It has two operating mechanisms: the old Hal and the new Hal, as shown in 3.

Figure 3 Hal running structure in Android

As shown in figure 3, the left side is the old Hal structure. The application or framework calls the so dynamic link library to access the hardware driver. In the so dynamic link library, the access logic of the driver is processed. We focus on learning and understanding the Hal stub method, and rIL also adopts the design concept of this method.

Hal stub is a proxy concept. Although stub still exists in the form of *. So, Hal has hidden the specific implementation of *. So. Stub provides the operations method to Hal. runtime obtains its operations method through the so method provided by stub and informs runtime of the callback method. In this way, both runtime and stub have methods called by the other party. An application request uses runtime to call the operations method of stub. After stub responds to the Operations method, then call the callback method of runtime to return the result. Here, there may be a bit of wrap, which is easier to understand based on the previous description and then combined with figure 4.

 

Figure 4 Hal stub Structure

The upper layer calls the underlying hardware through the functions provided by Hal. After the underlying hardware completes the upper-layer request processing or the hardware status changes, the Hal layer calls back the upper-layer applications through the callback interface provided by runtime.

Hal stub has an inclusive relationship, that is, Hal contains many stub. Runtime can obtain and operate the operations corresponding to stub as long as the request type is described. Its implementation is mainly in the hardware. C and hardware. H files. In essence, it is also through the dlopen method to load the. So dynamic link library, so as to call the symbol (Symbol) in *. So.

------------------------------

This article is excerpted from an in-depth understanding of Android
: Telephony Principle Analysis and best practices, Author: Yang qingping.

Douban Web site: http://book.douban.com/subject/20480692/

Sample chapter trial: http://download.csdn.net/detail/hzbooks/5068008

In-depth understanding of Android
: Telephony Principle Analysis and Best Practices: This article deeply analyzes the architecture design and implementation principles of Android telephony from the source code perspective, and deeply reveals the communication mechanism of Android. For Android Application Development engineers and System Engineers, "in-depth understanding of Android: telephony Principle Analysis and Best Practices" is a rare research and learning material. The book consists of 13 chapters, divided into five parts: The first part (1 ~ Chapter 3) first introduces the system structure of the smartphone, the architecture of the Android system, and the structure of the Telephony framework. Then, describes in detail how to build the android Source Code compiling environment and the reading environment, and the technical preparations to be made by reading "in-depth understanding of Android: telephony principles and best practices"; Part 2 (4 ~ Chapter 6). The call function of Android is deeply analyzed, including the call process, the active dialing and incoming call processes, and the call application mechanism, and analyzes the implementation mechanism of mobile phone communication functions at the framework layer and application layer. Part 3 (7 ~ Chapter 9), which provides an in-depth analysis of the communication functions of Android, including the analysis of the running mechanism of the network service status and the implementation mechanism of the online access of Android mobile phones, and the analysis of the process of sending and receiving short messages. Part 4 (10 ~ Chapter 12) for Android
RIL's working mechanism is deeply analyzed, including the analysis of the rilj Running Mechanism in the framework layer and the analysis of the rilc system structure and libril operating mechanism, the fifth part (chapter 13) analyzes the system services provided by the Telephony module, this includes the System Service Registration Portal and instances that call system service interfaces.

Yang qingping, Senior Android system engineer and software development engineer, is keen on the study of Android source code and system principles, the system architecture and design principles of Android, as well as the working mechanism of core functional modules such as telephony and framework are thoroughly studied. He is currently working at thundersoft, a leading provider of androidos in China, and serves as a System Architect. He also has a deep understanding of J2EE, UML, design patterns and other related technologies, as well as the operation modes and business development plans of important software industries such as value-added telecommunications services, e-commerce, and Iot. In addition, he is also an experienced lecturer with many years of talent training experience and is good at summing up and sharing.