Understanding Android-II (Kernel & HAL)

In this article, I’ll give you a contrast on Kernel and HAL in Android.

The foundation of the Android platform is the Linux kernel.

The Linux kernel is an extremely important part of the software on nearly every Android device. Android relies on the Linux kernel for underlying functionalities such as threading and low-level memory management. Using a Linux kernel allows Android to take advantage of key security features and allows device manufacturers to develop hardware drivers for a well-known kernel.

As the base for a mobile computing environment, the Linux kernel provides Android with several key security features, including:

1. A user-based permissions model
2. Process isolation
3. An extensible mechanism for secure IPC
4. The ability to remove unnecessary and potentially insecure parts of the kernel

As a multiuser operating system, a fundamental security objective of the Linux kernel is to isolate user resources from one another. The Linux security philosophy is to protect user resources from one another. Thus, Linux:

1. Prevents user A from reading user B’s files
2. Ensures that user A does not exhaust user B’s memory
3. Ensures that user A does not exhaust user B’s CPU resources
4. Ensures that user A does not exhaust user B’s devices (for example, telephony, GPS, and Bluetooth)

Android 8.0 introduced a modular kernel, splitting the device kernel into a system-on-chip (SoC), device, and board-specific deliverables. This change made it possible for original device manufacturers (ODMs) and original equipment manufacturers (OEMs) to work in isolated, board-specific trees for board-specific features and drivers, enabling them to override common kernel configurations, add new drivers in the form of kernel modules, etc.

HAL stands for Hardware Abstraction Layer

A HAL defines a standard interface for hardware vendors to implement, which enables Android to be agnostic about lower-level driver implementations. Using a HAL allows you to implement functionality without affecting or modifying the higher-level system.

HAL Types
In Android 8.0 and higher, the lower-level layers are re-written to adopt a new, more modular architecture. Devices running Android 8.0 and higher must support HALs written in HIDL, with a few exceptions listed below. These HALs can be binderized or passthrough. In Android 11, HALs written in AIDL are also supported. All AIDL HALs are binderized.

Binderized HALs, HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only.

Passthrough HALs, A HIDL-wrapped conventional or legacy HAL. These HALs wrap existing HALs and can serve the HAL in binderized and same-process (passthrough) modes. Devices upgrading to Android 8.0 can use passthrough HALs.

For each and every hardware component present in the device, a HAL has to be implemented in the shared library modules(.so files)

To guarantee that HALs have a predictable structure, each hardware-specific HAL interface has properties defined in the header file. This interface allows the Android system to load correct versions of your HAL modules in a consistent way. A HAL interface consists of two components: modules and devices.

HAL Modules:

A module represents your packaged HAL implementation, which is stored as a shared library (.so file). The hardware/libhardware/include/hardware/hardware.hheader file defines a struct (hw_module_t) that represents a module and contains metadata such as the version, name, and author of the module. Android uses this metadata to find and load the HAL module correctly.

In addition, the hw_module_t the struct contains a pointer to another struct, hw_module_methods_t, which contains a pointer to an open function for the module. This open function is used to initiate communication with the hardware for which the HAL is serving as an abstraction. For example, in the camera HAL, the camera_module_t struct contains a hw_module_t struct along with other camera-specific function pointers.

HAL Devices:

A device abstracts the hardware of your product. For example, an audio module can contain a primary audio device, a USB audio device, or a Bluetooth A2DP audio device.

A device is represented by the hw_device_t struct. Similar to a module, each type of device defines a detailed version of the generic hw_device_t that contains function pointers for specific features of the hardware. For example, the audio_hw_device_t struct type contains function pointers to audio device operations

In addition to these standard properties, each hardware-specific HAL interface can define more of its own features and requirements.