Simple and simple-Android system porting and Platform Development (vii)-first-knowledge hal__android

1. Hal's module and stub

The HAL (Hardware abstractlayer) Hardware abstraction layer is the top application of Google's Android system that shields a layer of software from the underlying hardware, and plainly, the top application doesn't care how the underlying hardware works, As long as a unified interface is provided to the upper layer, this design idea is widely existed in the current software architecture design.

Strictly speaking, the Android system is completely without the HAL hardware abstraction layer, the upper application layer can be called through the API to the underlying hardware, but Android has been in the banner of Open source since its inception, and some hardware manufacturers because of commercial factors, do not want their core code open source, Instead, it only provides binary code. In addition, some of the hardware device interfaces used in the Android system may not be a unified interface for Linux kernel, and the reason for the GPL copyright, so Google is not selfish, in the Android architecture of the HAL concept, This HAL is really hardware independent, the Android system is not dependent on a specific hardware driver, but rely on the HAL code, so that Third-party vendors can be their own code of not open source packaging in the HAL layer, only to provide binary.

The HAL architecture is divided into two types:

Ø Old schema Module

Ø New Architecture Modulestub

1.1 module Architecture

The old architecture is better understood, the Android user application or framework layer code is implemented by Java, Java running in the Dalvik virtual machine, there is no way to directly access the underlying hardware, only through the call so local library code implementation, in so local library code has the underlying hardware operation code, as shown in the following figure:

In other words, the application layer or framework layer Java code, through the JNI technology call C or C + + written so library code, in the so library code call the underlying driver, implementation of the upper application of the proposed hardware request operation. The so library that implements the hardware operation is: module.

The implementation process of the following diagram:

This shows that the Java code to access the hardware efficiency is very low, no C code efficiency, but the Android system in the software framework and hardware processors are in the reduction and C code execution efficiency gap, according to the results of foreign testing, basically can achieve C code efficiency of about 95%.

Although this design architecture satisfies the need of Java application access hardware, the coupling between the upper and lower layers of our code is too high, the user program or framework code has to load the module library, if the underlying hardware changes, moudle to recompile, the upper layer should make corresponding changes, in addition, If more than one application accesses the hardware at the same time, the module is loaded and the same module is mapped more than once by multiple processes, and there is a problem with the code being reentrant. As a result, Google has proposed a new HAL architecture.

1.2 The new HAL schema

The new schema uses the module stub method. Stub is the meaning of stub or pile, in fact, it means that an object represents the meaning. It is known from the above architecture that the upper application layer or framework layer code loads the so library code, so library code we call module, registers the stub stub of each hardware object at the HAL layer, and when the upper layer needs access to the hardware, it looks up from the currently registered hardware object stub. Once found, the stub provides the upper module with the operations Interface (operator interface) of the hardware object, which is stored in module, and the upper application or framework accesses the hardware through the module operator interface. The illustration below, taking led as an example:

Led app for Android applications, led app Java code can not operate hardware, the hardware operation to the local module library led_runtime.so, it from the current system to find the LED Stub, after the LED Stub to return hardware-driven operations to the Module,led app operation hardware, indirect access to the underlying hardware through the operating interface stored in module.

Here's the problem:

O Trouble, feel more complex than module mode

Ø How the Hardware object is registered as stub.

Ø How to find the stub of hardware object?

"Trouble" is certain, but Google's smart company is unlikely to be a trouble-maker, and it must be done in the light of other advantages.

comparison between 1.3Module architecture and stub architecture

In the module schema, the local code is implemented by the so library, which maps the so library directly into the process space, with the code reentrant and the device open more than once. Although the new stub framework will also load the module library, the module does not contain the ability to operate the underlying hardware driver, which holds only the operating interface provided by the underlying stub, which acts as the "interface provider" and is loaded into memory the first time the stub is used. Only the Hardware object operator interface is returned for subsequent reuse, the device does not have multiple open issues, and the code does not return to the problem because it returns just the function pointer when the multiple process accesses.