Deep dive-Android system migration and platform development (7)-First knowledge of Hal

1. Hal module and stub

The Hardware Abstraction Layer of Hal (hardware abstractlayer) is a software layer used by upper-layer applications in Google's Android system to block underlying hardware operations. To put it bluntly, that is, upper-layer applications do not need to care about how the underlying hardware works. They only need to provide a unified interface to the upper-layer. This design concept is widely used in the current software architecture design.

Strictly speaking, there is no HAL Hardware Abstraction Layer in the Android system, and the upper-layer application layer can call the underlying hardware through APIS. However, Android has always been under the banner of open source since its appearance, some hardware vendors do not want their core code to be open-source due to business factors, but only provide binary code. In addition, some hardware device interfaces used in the Android system may not be the unified Linux kernel interfaces used, and GPL copyright causes, So Google is not self-interested, the Hal concept is put forward in the android architecture. This Hal actually means hardware independence. The Android system depends on Hal code instead of a specific hardware driver, third-party vendors can encapsulate their own non-open source code on the Hal layer and only provide binary.

Hal has two architectures:

Ø Old Architecture Module

Ø New Architecture modulestub

1.1 Module Architecture

The old architecture is easy to understand. The Android user application or framework layer code is implemented by Java, and Java runs in the Dalvik virtual machine. There is no way to directly access the underlying hardware, you can only call the so local library code. The so local library code contains the underlying hardware operation code, as shown in:

That is to say, the application layer or framework layer Java code calls the so library code written by C or C ++ through JNI technology and calls the underlying driver in the so library code, implement hardware request operations from upper-layer applications. The so library that implements hardware operations is module.

The implementation process is as follows:

It can be seen that the hardware access efficiency of Java code is quite low, without the high efficiency of C code, but the Android system is reducing the gap between the implementation efficiency of C code and the software framework and hardware processor, according to the results of tests outside China, the efficiency of C code is basically about 95%.

Although this design architecture satisfies the needs of Java applications to access hardware, the coupling between the upper and lower layers of our code is too high, and the user program or framework code must load the module library, if the underlying hardware changes, Moudle needs to be re-compiled and the upper layer needs to be changed accordingly. In addition, if multiple applications access the hardware at the same time, all modules are loaded, the same module is mapped multiple times by multiple processes, and code re-entry may occur. Therefore, Google proposed a new Hal architecture.

1.2 New Hal Architecture

The new architecture uses the module stub method. Stub refers to the meaning of a stub or pile. To put it bluntly, it refers to the meaning represented by an object. According to the above architecture, the code of the so library is loaded at the upper application layer or framework layer. The so library code is called module, and the stub of each hardware object is registered at the Hal layer, when the upper layer needs to access the hardware, it searches for the currently registered hardware object stub. After finding it, Stub will provide the Operations interface (Operation Interface) of the hardware object to the upper layer module ), this operation interface is saved in the module, and the upper-layer application or framework accesses the hardware through this module operation interface. For example, taking led as an example:

 

The LED app is an android application, and the Java code in the LED app cannot operate the hardware. The hardware operation is handed over to the local module library led_runtime.so, which searches for the LED stub in the current system, led stub returns the hardware driver operation to the module. When operating the hardware, the LED app indirectly accesses the underlying hardware through the operation interface stored in the module.

Question:

Ø troublesome. I think it is more complicated than the module method.

How can I register a hardware object as a stub?

Ø how can I find the stub of the hardware object on the upper layer?

The "trouble" is definite, but Google's smart company cannot be a light manufacturing company. It must be used in consideration of other advantages.

1.3module architecture and stub architecture comparison

In the module architecture, the local code is implemented by the so library, and the so library is directly mapped to the process space at the upper layer, which may cause code re-entry and multiple device opens. Although the new stub framework also needs to load the module library, this module does not include the function for operating the underlying hardware driver. It only saves the operation interface provided by the underlying stub, the underlying stub plays the role of "interface provider". When stub is used for the first time, it is loaded into the memory. When it is used for the first time, only the hardware object operation interface is returned, which does not cause multiple device opens, in addition, the returned result is only a function pointer during multi-process access, and the code is not reentrant.