Explain the profound things in a simple way-Android system transplantation and platform development (7)-First acquaintance with HAL
1. HAL module and stub
HAL (Hardware AbstractLayer) hardware abstraction layer is a software layer in the Android system developed by Google that shields the operation of the underlying hardware from the upper-level application. To put it bluntly, the upper-level application does not need to care about how the underlying hardware works, as long as it provides a unified interface to the upper layer. That is to say, this design idea widely exists in the current software architecture design.
Strictly speaking, there is no HAL hardware abstraction layer in the Android system. The upper application layer can call the underlying hardware through APIs. However, Android has been under the banner of open source since its appearance, and some hardware manufacturers do not want their own due to commercial factors. The core code is open source, but only binary code is provided. In addition, some of the hardware device interfaces used in the Android system may not be the unified interface of the Linux Kernel used, and there are reasons for GPL copyright, so Google is disadvantageous and proposed the concept of HAL in the Android architecture. This HAL is actually hardware. Independence means that the Android system does not depend on a specific hardware driver, but on the HAL code. In this way, third-party manufacturers can encapsulate their non-open source code in the HAL layer and only provide binary.
The HAL architecture is divided into two types:
Ø Old architecture module
Ø New architecture modulestub
1.1 module architecture
The old architecture is easier to understand. Android user application or framework layer code is implemented by Java. Java runs in the Dalvik virtual machine. There is no way to directly access the underlying hardware. It can only be implemented by calling the so local library code, in the so local library code. There are operating codes for the underlying hardware, as shown in the figure below:
That is to say, the application layer or framework layer Java code calls the so library code written in C or C++ through JNI technology, and calls the bottom driver in the so library code to implement the hardware request operation proposed by the upper application. The so library that implements hardware operations is: module.
The implementation process is as follows:
It can be seen that the efficiency of Java code to access the hardware is actually quite low, and it is not as efficient as C code, but the Android system is reducing the gap with C code execution efficiency in the software framework and hardware processor. According to the results of foreign tests , Basically can reach about 95% of the efficiency of C code.
Although this design architecture meets the needs of Java applications to access the hardware, it makes the coupling between the upper and lower levels of our code too high. The user program or framework code must load the module library. If the underlying hardware changes, the moudle must be recompiled The upper layer also needs to make corresponding changes. In addition, if multiple applications access the hardware at the same time, they all load the module. If the same module is mapped multiple times by multiple processes, there will be code reentry problems. Therefore, Google has proposed a new HAL architecture.
1.2 New HAL architecture
The new architecture uses the module stub approach. Stub means stub or stub. In fact, to put it plainly, it means what an object represents. It can be seen from the above architecture that the upper application layer or framework layer code loads the so library code. The so library code is called module. The stub of each hardware object is registered in the HAL layer. When the upper layer needs to access the hardware, it starts from the current Search in the registered hardware object stub. After it is found, the stub will provide the operations interface of the hardware object to the upper module. The operation interface is stored in the module, and the upper application or framework can access the hardware through the module operation interface. . As shown in the figure below, a schematic diagram of Led as an example:
The Led App is an Android application. 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. It searches for the Led Stub in the current system. After finding it, the Led Stub returns the hardware driver operation When operating the hardware for the module, the Led App indirectly accesses the underlying hardware through the operating interface stored in the module.
Here comes the problem:
Ø Troublesome, feel more complicated than module
Ø How to register a hardware object as a stub?
Ø How does the upper layer find the stub of the hardware object?
"Trouble" is certain, but a company as smart as Google cannot be a company that only causes trouble. It must be used in consideration of other advantages.
1.3 Comparison of Module Architecture and Stub Architecture
In the Module architecture, the local code is implemented by the so library, and the upper layer directly maps the so library into the process space. There will be problems with code reentry and multiple openings of the device. Although the new Stub framework also needs to load the module library, this module no longer contains the function of operating the underlying hardware driver. It only stores the operation interface provided by the underlying Stub, and the underlying Stub plays the role of the "interface provider". The stub is loaded into the memory when it is used for the first time, and only returns to the hardware object operation interface when it is used later. There is no problem of opening the device multiple times, and since the function pointer is returned during multi-process access, the code has no reentrant problem.
https://blog.csdn.net/mr_raptor/article/details/8069588
------------------------------------------------------------------------------------------------------------------------------------
The origin of HAL, why is android not an open source system
Android's hardware abstraction layer, in simple terms, is the encapsulation of the Linux kernel driver, providing an interface upwards and shielding the implementation details of the low-level . In other words, the hardware support is divided into two layers, one layer is placed in the user space (User Space), and the other layer is placed in the kernel space (Kernel Space). Among them, the hardware abstraction layer runs in the user space , and the Linux kernel driver The program runs in the kernel space. Why should we arrange this? Is it not feasible to integrate the hardware abstraction layer and the kernel driver in the kernel space? From a technical point of view, it is possible, but from a commercial point of view, placing the hardware support logic in the kernel space may harm the interests of manufacturers. We know that the Linux kernel source code copyright follows the GNU License, while the Android source code copyright follows the Apache License. The former must publish the source code when releasing the product, while the latter does not need to publish the source code. If all the codes for hardware support are placed in the Linux driver layer, it means that the source code of the driver must be disclosed when released, and the disclosure of the source code means that the relevant parameters and implementation of the hardware are disclosed, and in the mobile phone market In today's fierce competition, this is very harmful for manufacturers. Therefore, Android will think of dividing the hardware support into a hardware abstraction layer and a kernel driver layer. The kernel driver layer only provides simple access to the hardware logic, such as the channel to read and write hardware registers, as to what values are read or written from the hardware All the logic in the hardware is placed in the hardware abstraction layer , so that trade secrets can be hidden. It is precisely because of this layering that Android was kicked out of the Linux kernel mainline code tree. Think about it, the Android driver in the kernel space has incomplete hardware support. When the Linux kernel is ported to other machines, the hardware is completely unusable due to the lack of hardware abstraction layer support. That's why He said Android is an open system rather than an open source system for a reason.
