In short, the hardware abstraction layer of Android encapsulates the Linux kernel driver and provides interfaces up to shield implementation details at the lower layer. That is to say, the hardware support is divided into two layers: one layer in the user space and the other layer in the kernel space, where the hardware abstraction layer runs in the user space, the Linux Kernel Driver runs in the kernel space. Why is this arrangement necessary? Is it not feasible to integrate the hardware abstraction layer with the kernel driver into the kernel space? From the technical implementation point of view, yes. However, from the commercial point of view, putting the hardware support logic in the kernel space may harm the interests of the manufacturer. We know that the Linux kernel source code copyright complies with the GNU license, while the android source code copyright complies with the Apache license. The former must publish the source code when releasing the product, and the latter does not need to publish the source code. If you place all the code supported by the hardware on the Linux driver layer, it means that the source code of the driver must be published at the time of release, the open source code means that the hardware-related parameters and implementations are made public. In today's fierce competition in the mobile phone market, the damage is very huge for manufacturers. Therefore, Android will think of dividing hardware support into hardware abstraction layer and kernel driver layer. The kernel driver layer only provides simple access to hardware logic, such as reading and writing hardware registers, as for what value is read from the hardware or what value is written to the logic in the hardware, it is placed in the hardware abstraction layer, so that the trade secrets can be hidden. Because of this layering, Android is kicked out of the main line code tree of the Linux kernel. The driver program for Android in the kernel space does not provide complete hardware support. When we port the Linux kernel to another machine, the hardware abstraction layer is not supported, hardware is completely unavailable, Which is why Android is an open system rather than an open source system.
Aside from these arguments, learning the Android hardware abstraction layer is extremely useful for understanding the entire android system, it involves the hardware driver layer, hardware abstraction layer, Runtime Library, and application framework layer of the Android system, the following figure illustrates the location of the hardware abstraction layer in the Android system and its relationship with other layers:
When learning the Android hardware abstraction layer, we will learn how to write hardware drivers in the kernel space, how to add interfaces in the hardware abstraction layer to support hardware access, how to provide hardware access services at system startup, and how to write JNI to enable access hardware through Java interfaces, as an episode in the middle, we will also learn how to add a C executable program in the Android system to access the hardware driver. As this is a systematic learning process, I will divide it into six articles to describe each learning process, including:
1. Compile the hardware driver in the android kernel source code project.
2. Add a C executable program in the Android system to access the hardware driver.
3. added an interface module to the Android hardware abstraction layer to access the hardware driver.
4. Compile the JNI method in the Android system and provide Java interfaces to access the hardware at the application framework layer.
5. Added hardware service interfaces at the application framework layer of the Android system.
6. Write an app in the Android system to access the hardware service at the application framework layer.
After studying these six articles, I believe you will have a deeper understanding of the Android system. Please stay tuned.
Lao Luo's Sina Weibo: http://weibo.com/shengyangluo. welcome to the attention!