[Reprinted] Introduction to Android hal

About Android hal

1. Introduction to Hal

The existing Hal architecture was proposed by Patrick Brady (Google) in his 2008 Google Io speech, for example:

Android Hal is designed to protect the intellectual property rights of some hardware providers, and is designed to avoid GPL limitations of Linux. The idea is to put the hardware control actions in the android Hal, while the Linux driver only performs some simple data interaction actions, and even directly maps the hardware register space to the user space. Android is based on the license of Apache. Therefore, hardware vendors can only provide binary files. Therefore, Android knowledge is an open platform rather than an open-source platform. Maybe because Android does not follow GPL, Greg KH deletes the android driver from Linux in kernel 2.6.33. GPL and hardware vendors still have cracks that cannot be bridges. Android does not want to solve this problem easily.

To sum up, the main causes of the existence of Android Hal are:

1. Not all hardware devices have standard Linux kernel interfaces;

2. the kernel driver is copyrighted by GPL. Some device manufacturers do not want to disclose hardware drivers, so they use Hal to bypass GPL;

3. Android has some special requirements for some hardware.

 

2. In the android source code, Hal code is mainly located in the following directory:

1. libhardware_legacy/-old architecture, using the concept of connecting database modules;

2. libhardware/-new architecture, adjusted to halstub concept;

3. RIL/-radio interface layer, including 3G, GSM, and other telephone functions;

4. msm7k, qcom, AND Ti related to the platform

It mainly includes some modules: GPS, vibrator, WiFi, copybit, audio, camera, lights, rIL, and overlay.

 

3. Comparison between old and new hal

The Hal architecture is gradually improved. The new architecture is more abstract than the old one, and the android framework and Linux kernel are well isolated. So that android does not rely heavily on Linux kernel, so you do not have to consider the underlying hardware details when developing the android framework.

Old Hal Architecture

The old Hal architecture is a more traditional module mode, that is, the *. So file is used as the sharedlibrary, And the Hal module is used in the runtime (JNI part) with direct function call. You can directly call the function to operate the driver.

Of course, the application does not need to use JNI (Black Arrow) to load directly *. so Library (dlopen) method to call *. so symbol is also a method.

In short, the upper layer directly operates the hardware without being encapsulated.

 

New Hal Architecture

The new Hal architecture has the taste of stub. Hal stub is a kind of proxy concept. Although stub is still in stock with *. So, Hal has encapsulated *. So library. Stub provides operational functions to Hal, while runtime obtains the operations of a specific module (stub) from Hal. In this indirectfunction call architecture, Hal stub becomes an inclusive relationship, that is, Hal contains many stub (agents ). As long as the runtime type is described, that is, the module ID, the operation function can be obtained.

 

Hal's future development

The new Hal approach tends to adopt JNI in all aspects. That is, in the android architecture, modify androidruntime (core library) and perform the callback operation after obtaining the operations of the Hal module. Place the Hal module in Hal.

Source Address: http://www.jollen.org/blog/2009/10/android-hal-status-report.html