Android HAL in-depth exploration (1): Architecture overview

In this article, we will learn in depth about the different ways and architectures of Android HAL, as well as the differences and connections between them. It will start with the earliest Legacy HAL, and then introduce the new HAL definition method starting from Android 8.0 (Oreo): HIDL (Hardware Interface Definition Language). Two modes of HIDL will be compared: Passthrough mode and Binderized mode, and their respective advantages and disadvantages will be analyzed. Finally, we will summarize the role and significance of HAL and look forward to the future development direction. The code structure is based on the custom SystemGpio example (Legacy HAL).

Series of articles:
Android HAL in-depth exploration (1): Architecture overview
Android HAL in-depth exploration (2): Traditional HAL and file encryption and decryption simulation
Android HAL in-depth exploration (3): HIDL Passthrough mode and serial port data callback simulation
Android HAL in-depth exploration (4 ): HIDL Binderized mode and CAN data callback simulation
Android HAL in-depth exploration (5): Debugging HAL error reports and solutions

0.Reference learning

Hardware Abstraction Layer (HAL) Overview
HIDL C++ | Android Open Source Project
HAL Type | Android Open Source Project
HIDL Detailed Explanation - Android10.0 HwBinder Communication Principle (2)
Rockchip Series Customized GPIO Interface Hardware Part (3)

1. Legacy HAL

Before HIDL, Android used traditional HAL, which was written in C language. This HAL defines a series of structures and function pointers, one of which hw_module_trepresents a hardware module. This style of HAL is usually located /hardware/libhardware/include/hardware/in a directory.

interactive mode

Traditional HAL needs to interact with the Android framework to provide hardware-related functions and services. In order to achieve this, traditional HAL needs to go through the following levels:

• Java Framework Interface : This is a Java class or interface defined in the Android framework, used to provide APIs for applications or services. For example, android.os.SystemGpioit is a Java class used to control the GPIO (General Purpose Input/Output) port.
• AIDL Interface : This is an AIDL (Android Interface Definition Language) file defined in the Android framework, which is used to describe the data types and method signatures that need to be passed or returned during cross-process communication. android.os.IGpioService.aidlIt is an AIDL file used to define the interface that the GPIO service needs to implement.
• Service Implementation in Java : This is a Java class in the Android framework that implements the AIDL interface. It is used to run in the background as a service and handle requests from other processes or applications. com.android.server.GpioServiceIt is a Java class used to implement GPIO services.
• JNI Layer : This is the C/C++ code in the Android framework that uses JNI (Java Native Interface) to bridge the interaction between the Java layer and the C layer. The JNI layer is responsible for converting the parameters passed by the Java layer into data types that can be recognized by the C layer, and calling the corresponding C functions. vice versa. com_android_server_GpioService.cppIt is a JNI layer file used to call GPIO HAL related functions.
• HAL Header : This is a C header file in traditional HAL that defines interface specifications such as structures and function pointers. These header files are usually located hardware/libhardware/include/hardware/in directories and _hal.hend with . gpio_hal.hIt is a HAL header file used to define GPIO HAL related interfaces.
• HAL Implementation : This is the C code that implements the interface specification defined in the HAL header file in traditional HAL. These codes are usually located hardware/libhardware/modules/in directories and _hal.cend with . gpio_hal.cIt is a HAL implementation file used to implement GPIO HAL related functions.
• Kernel Driver : This is the driver layer code that interacts directly with the hardware and is usually part of the operating system kernel. These codes are usually located kernel/drivers/in directories and end with .cor .h. gpio.cIt is a driver layer file used to control the input and output status of the GPIO port.

code architecture

The traditional HAL is the early hardware abstraction layer design of the Android system. Its main purpose is to provide a unified interface for the Android framework, so that the framework can interact with the underlying hardware without caring about the specific implementation of the hardware.

• Java Framework Interface:

  • frameworks/base/core/java/android/os/SystemGpio.java: This is the Java interface in the Android framework through which applications and system services interact with GPIO hardware.

• AIDL Interface:

  • frameworks/base/core/java/android/os/IGpioService.aidl: AIDL (Android Interface Definition Language) defines a cross-process interface that allows applications to communicate with GPIO services running in another process.

• Service Implementation in Java:

  • frameworks/base/services/core/java/com/android/server/GpioService.java: This is a Java implementation of a GPIO service that handles requests from applications and interacts with the underlying hardware via JNI.

• JNI Layer:

  • frameworks/base/services/core/jni/com_android_server_GpioService.cpp: JNI (Java Native Interface) layer allows Java code to interact with native C/C++ code. The JNI code here is to bridge the communication between the Java service and the HAL.

• HAL Header:

  • hardware/libhardware/include/hardware/gpio_hal.h: This is the header file of HAL, which defines the interface and data structures required to interact with the hardware.

• HAL Implementation:

  • hardware/libhardware/modules/gpio/gpio_hal.c: This is a C implementation of HAL, which interacts with the underlying hardware driver.

• Kernel Driver:

  • kernel/drivers/misc/gpio/gpio.c: This is the GPIO driver in the Linux kernel, which interacts directly with the hardware.

Architecture diagram

The traditional HAL architecture is shown in the figure below:

The advantage of traditional HAL is that it is simple and direct, easy to understand and implement. But it also has some shortcomings, mainly as follows:

• Lack of version control and backward compatibility : Traditional HAL has no clear version number and interface change mechanism. If the hardware supplier or the Android system needs to modify or extend the HAL interface, then all related codes need to be modified at the same time, including the JNI layer, framework layer and application layer . This makes maintaining and upgrading the code difficult and time-consuming.
• Lack of security and stability : The traditional HAL is directly linked to the client process as a library, which means that the calls between the client and the HAL are intra-process, without the overhead of inter-process communication. But this also means that if there is an error or crash in HAL, it will affect the client process and even cause the entire system to crash. Traditional HAL has no sandbox mechanism and no permission control. Any process can access any HAL module , which may bring security risks.

In order to solve the shortcomings of traditional HAL, Android has introduced a new HAL definition method: HIDL starting from 8.0 (Oreo).

HIDL (Hardware Interface Definition Language) is a language used to define the interface of HAL. HIDL provides better version control and backward compatibility than traditional HAL. HIDL also supports two different modes: Passthrough mode and Binderized mode. These two modes correspond to different communication methods and architectures.

2. HIDL Passthrough mode

interactive mode

In Passthrough mode, the HAL service runs as a library in the client process. This means that calls between the client and the HAL are in-process, without the overhead of inter-process communication. This mode is similar to traditional HAL, but has the following differences:

• Use C++ instead of C : The HIDL HAL in Passthrough mode is written in C++. This allows HAL to use C++ features such as classes, inheritance, polymorphism, etc.
• Use .hal instead of .h : HIDL HAL in Passthrough mode uses .halfiles to define interface specifications, not .hfiles. .halFile is a special syntax used to describe the data types and method signatures that need to be passed or returned in the HAL interface. .halFiles are usually located hardware/interfaces/in directories and .halend with . For example, IGpio.halit is a .halfile used to define GPIO HAL related interfaces.
• Use hidl-gen instead of writing code manually : The HIDL HAL in Passthrough mode uses a tool: to generate C++ and Java code hidl-genfrom files. .halThese codes include interface implementation, client proxy, service registration and other functions. This avoids manually writing repetitive and tedious code and ensures that the code is consistent with the interface specification.
• Use Android.bp instead of Android.mk : HIDL HAL in Passthrough mode uses a new build system: Soong to compile the code. Soong uses .bpfiles to describe the data types and method signatures that need to be passed or returned in the HAL interface. .halFiles are usually located hardware/interfaces/in directories and .halend with . IGpio.halIt is a .halfile used to define GPIO HAL related interfaces.
• Use Android.bp instead of Android.mk : HIDL HAL in Passthrough mode uses a new build system: Soong to compile the code. Soong uses .bpfiles instead of files to describe build rules and dependencies .mk. .bpThe files are usually located in the same directory as the HAL implementation code and .bpend with . Gpio.bpIt is a .bpfile used to compile GPIO HAL related code.

The advantage of Passthrough mode is high performance and no inter-process communication overhead. But it also has some shortcomings, mainly as follows:

• Lack of security and stability : Passthrough mode still has the security and stability issues of traditional HAL. Because the HAL service runs as a library in the client process, if an error or crash occurs in HAL, it will affect the client process and even cause the entire system to crash. Passthrough mode also has no sandbox mechanism and no permission control. Any process can access any HAL module, which may bring security risks.
• Lack of flexibility and scalability : HIDL HAL in Passthrough mode can only be linked to the client process as a library, which means that the client must be a C++ native service or application. If the client is a Java layer application or service, then the JNI layer is still needed to bridge the interaction between Java and C++. This increases code complexity and maintenance costs. Passthrough mode also does not support multiple clients accessing the same HAL service at the same time, which will limit the scalability of the HAL service.

In order to solve the shortcomings of Passthrough mode, Android also provides another HIDL mode: Binderized mode.

code architecture

HIDL (Hardware Interface Definition Language) is a new hardware abstraction mechanism introduced in Android Oreo (8.0). Passthrough mode is one of the modes that allows the HAL to run in a traditional way but interact with the Android framework through the HIDL interface.

• Java Framework Interface:

  • frameworks/base/core/java/android/os/SystemGpio.java: This is the Java interface in the Android framework through which applications and system services interact with GPIO hardware.

• HIDL Interface Definition:

  • hardware/interfaces/gpio/1.0/IGpio.hal: This is an interface defined by HIDL that describes how to interact with GPIO hardware.

• Native Service Implementation:

  • frameworks/base/services/core/jni/com_android_server_GpioService.cpp: If the Java layer needs to access the hardware directly, it will interact with the HIDL interface through this JNI layer.

• HAL Implementation:

  • hardware/interfaces/gpio/1.0/default/Gpio.cpp: This is the implementation of HIDL HAL, which interacts with the underlying hardware driver.

• Kernel Driver:

  • kernel/drivers/misc/gpio/gpio.c: This is the GPIO driver in the Linux kernel, which interacts directly with the hardware.

Architecture diagram

The architecture of HIDL HAL in Passthrough mode is shown in the figure below:

3. HIDL Binderized mode:

interactive mode

In Binderized mode, the HAL service runs as an independent process. Communication between client and HAL is through Binder IPC. This mode is different from Passthrough mode, but has the following points in common:

• Use C++ instead of C : The HIDL HAL in Binderized mode is also written in C++.
• Use .hal instead of .h : HIDL HAL in Binderized mode also uses .halfiles to define interface specifications.
• Use hidl-gen instead of writing code manually : HIDL HAL in Binderized mode is also used hidl-gento generate C++ and Java code from .halfiles.
• Use Android.bp instead of Android.mk : HIDL HAL in Binderized mode also uses Soong to compile the code.

The advantage of the Binderized mode is high security and stability, because the HAL service runs in its own sandbox environment and can be permissioned through SELinux. The Binderized mode also supports multiple clients to access the same HAL service at the same time, improving the scalability of the HAL service. But it also has some shortcomings, mainly as follows:

• Low performance : HIDL HAL in Binderized mode requires cross-process communication through Binder IPC, which brings additional overhead and latency. Especially for some hardware services with high frequency or low latency requirements, such as audio, video, sensors, etc., Binder IPC may affect its performance and experience.
• High complexity : HIDL HAL in Binderized mode needs to implement an independent service process, which will increase the code complexity and maintenance costs. Especially for some simple or infrequently used hardware services, such as GPIO, LED, etc., it may be unnecessary to implement an independent service process.

code architecture

Binderized mode is another mode of HIDL where HAL runs as a separate process and interacts with the Android framework through Binder IPC.

• Java Framework Interface:

  • frameworks/base/core/java/android/os/SystemGpio.java: This is the Java interface in the Android framework through which applications and system services interact with GPIO hardware.

• HIDL Interface Definition:

  • hardware/interfaces/gpio/1.0/IGpio.hal: This is an interface defined by HIDL that describes how to interact with GPIO hardware.

• HAL Service Implementation:

  • hardware/interfaces/gpio/1.0/service/GpioService.cpp: This is the HAL service implementation in Binderized mode, which runs as an independent process and interacts with the Android framework through Binder IPC.

• Kernel Driver:

  • kernel/drivers/misc/gpio/gpio.c: This is the GPIO driver in the Linux kernel, which interacts directly with the hardware.

Architecture diagram

The architecture of HIDL HAL in Binderized mode is shown in the figure below:

Summary: HIDL provides two different modes: Passthrough mode and Binderized mode. These two modes correspond to different communication methods and architectures. Passthrough mode has high performance, but low security and stability. Binderized mode has high security and stability, but low performance. You can choose the appropriate mode based on specific hardware services and needs.

The role and significance of HAL

HAL is a bridge between the Android system and hardware. It provides a standard interface for the Android framework, allowing the Android framework to interact with a variety of hardware without knowing the specific implementation details of the hardware. The functions and significance of HAL mainly include the following points:

• Improved compatibility between hardware vendors and the Android system : Through HAL, hardware vendors can provide their hardware with an interface that meets Android specifications without having to modify their drivers or the Android system. This makes it easier for hardware vendors to adapt their hardware to the Android platform and update their drivers faster.
• Improved abstraction between the Android system and applications : Through HAL, the Android system and applications can use a unified API to access hardware services without having to care about the specific implementation details of the hardware. This makes it easier for Android systems and applications to support multiple hardware platforms and devices, and to expand and optimize their functions more flexibly.
• Improved security and stability between Android systems and applications : Through HAL, Android systems and applications can restrict access to hardware services through sandbox mechanisms and permission control, preventing malicious or erroneous operations from causing damage to hardware or systems. . Through HAL, the Android system and applications can also isolate or recover problems caused by errors or crashes in hardware services to ensure the normal operation of the system and applications.

future development direction

As the Android system and hardware platform continue to develop and innovate, HAL will also change and evolve accordingly. Possible development directions:

• More HIDLization : HIDL is a new way of defining HAL, which provides better version control and backward compatibility. Currently, HIDL has covered most hardware services, such as audio, video, sensors, cameras, etc. But there are still some traditional HAL that have not been HIDLized, such as power management, memory management, etc. In the future, we may see more traditional HALs being HIDLized to improve their compatibility and maintainability.
• More Binderized : Binderized mode is a new HAL communication method that provides higher security and stability. Currently, the Binderized mode is applicable to most HIDL HALs, such as audio, video, sensors, cameras, etc. But there are still some Passthrough modes that have not been Binderized, such as GPIO, LED, etc. It is possible to see more Passthrough patterns being Binderized to improve their security and scalability.
• More VTS : VTS (Vendor Test Suite) is a new HAL testing tool that can automatically conduct functional, compatibility, security and performance testing of HAL. Currently, VTS has supported most HIDL HALs, such as audio, video, sensors, cameras, etc. But there are still some HALs that have not been VTSized, such as power management, memory management, etc. We may see more HALs being VTSized to improve their quality and reliability.

Summarize

Android HAL is an important component that provides a standard interface between the Android system and hardware. The different methods and architectures of HAL reflect the continuous development and innovation of Android systems and hardware platforms. In this article, we deeply explore the basic concepts of three ways to learn Android HAL: Legacy HAL, HIDL Passthrough mode and HIDL Binderized mode, and analyze the differences and connections between them. It also summarizes the role and significance of HAL and looks forward to the future development direction.