What a HAL is

A camera is a sensor, a lens, an actuator and a bus. The Android framework does not want to know about any of that. It wants to say "give me a preview at 1080p" and get frames back. The thing in between is a HAL.

TL;DR#

• A HAL is the contract between the framework and hardware. It describes operations, not implementations.
• Before Android 8.0, a HAL was usually a shared library dlopened into the framework process, reached through a C struct of function pointers.
• After Android 8.0, a HAL is usually a separate process reachable over Binder (glossary definition), described in AIDL (glossary definition) (or historically HIDL (glossary definition)).
• The HAL exists because the vendor writes it and Google cannot. Standardising the boundary is what lets one framework ship on hundreds of different camera sensors.
• Every HAL is declared in a VINTF (glossary definition) manifest, so the phone can verify at boot that the pieces it has match the pieces it needs.

Mental model#

Think of a wall socket.

You do not need to know whether the electricity comes from a hydro dam or a gas turbine. You need to know that the socket takes a plug of a particular shape and delivers a particular voltage. The socket is the interface; the power station is the implementation.

A HAL is a wall socket for hardware. The camera HAL is the socket; the sensor driver and the ISP firmware are the power station.

Where the analogy breaks#

Wall sockets are standardised by committees over decades. Android has several generations of socket at once, and the shape changed underneath the appliance twice: once when HALs moved from in-process libraries to Binder services (Android 8.0), and once when the interface language moved from HIDL to AIDL (from Android 11 onward, with HIDL deprecated as of Android 13). A device can have all of these at once, which is why "the HAL" is not one thing.

The big picture#

Deep dive#

The legacy HAL: a struct of function pointers#

Before Android 8.0, the HAL interface was defined by hardware/libhardware. A HAL was a shared object with a known name, and the framework loaded it at runtime.

The mechanism was a C struct with a magic number and a version, plus a device struct with function pointers.¹ The framework called hw_get_module() with a module ID, got back a hw_module_t, called its open() method, and received an hw_device_t whose function pointers were the actual operations.

Three properties followed from that design, and all three were problems:

• Same address space. The vendor library ran inside the framework's process. A crash in the vendor code crashed the framework; a memory bug in the vendor code could corrupt framework state.
• No version in the call. The contract was the C header. If the header changed, the caller had to be recompiled. There was a version field in the struct, but it was a coarse integer, not a negotiated interface.
• No enumeration. A HAL existed if its .so was on the system. There was no way to ask the device "what HALs do you have" and get a structured answer.

The modern HAL: a process and an interface#

The modern HAL keeps the same idea — a contract — and changes the transport and the description.

The transport is Binder. A HAL service is a process, started by init, that registers itself with a service manager under a name. The framework looks up the name and gets a proxy.

The description is an interface definition language. HIDL was the first, introduced with Treble. AIDL, which already existed for app-to-framework IPC, became the recommended language for HALs and is now the only one for new work.

The consequences are the mirror image of the legacy problems:

• Separate address space. A HAL crash is a process death. The service is restarted.
• Version in the name. android.hardware.camera.provider@2.4 is not the same interface as @2.5, and both can exist.
• Enumeration. The VINTF manifest declares exactly which HALs the device provides.

What a HAL interface looks like#

A modern HAL is an AIDL interface in a package under hardware/interfaces. The package name encodes the domain, and the interface name encodes the capability:

hardware/interfaces/vibrator/aidl/android/hardware/vibrator/IVibrator.aidl

The instance name a client looks up is the package, the interface and the instance, joined with dots and a slash:

android.hardware.vibrator.IVibrator/default

The framework asks for that name, gets a proxy, and calls getCapabilities(), on(), off(). It does not know whether the implementation is a tiny motor driver or a haptic engine with a DSP.

The four HALs you have already used#

Even if you have never written a HAL, you have depended on four of them.

Each of these is a place where the framework's behaviour is fixed and the hardware's behaviour is not. That is the entire justification for the abstraction.

Costs#

A HAL boundary is not free, and pretending otherwise makes the design hard to reason about.

• Latency. A Binder transaction is microseconds, not nanoseconds. For a sensor at 200 Hz, one transaction per sample would be absurd, which is why sensor data flows through shared memory and the service is a control plane.
• Complexity. A HAL needs a process, an .rc file, a SELinux domain, a VINTF entry and a service registration. The legacy .so needed a makefile rule.
• Versioning discipline. Once an interface is published it cannot change incompatibly. That constrains the vendor as much as the platform.

The trade is deliberate: the platform pays complexity once so it does not pay a fork per device.

Lifecycle: HALs can sleep#

A HAL process that is always running costs memory even when nothing is using the camera. Modern Android lets HALs be lazy: the service starts on first request and exits when it has no clients.

The mechanism is documented in the dynamic lifecycle page: a HAL declares that it should not start automatically, hwservicemanager starts it when a client asks for an unregistered service, and the HAL uses a registrar that tracks client references so it can shut down when the last one goes away. The API is LazyServiceRegistrar for HIDL; AIDL HALs have an equivalent.³

How it evolved#

The arc is: in-process library (2008–2017), binderized and versioned (2017–2020), AIDL and lazy (2020 onward). Each step moved more of the contract into something machine-checkable — a header, then a .hal file, then an .aidl file with @VintfStability.

Under the hood#

• ‹›↗every AOSP HAL interface, organised by domain
• ‹›hardware.h↗the legacy HAL contract: hw_module_t, hw_device_t, hw_get_module
• ‹›IVibrator.aidl↗a small, readable modern HAL interface
• ‹›↗the library that reads manifests and compatibility matrices

Curiosity corner#

• The same physical camera can appear as several logical cameras. The camera HAL exposes them; the framework has no idea they share a sensor.
• A HAL does not have to be written by the hardware vendor. Some are written by Google or by the OEM, especially where the hardware is standard (a vibrator, a light).
• The audio HAL is one of the oldest surviving interfaces. Its shape has changed far less than the camera's, because audio hardware has changed far less.

Try it#

$ 
adb shell service list | grep "android.hardware"
adb shell dumpsys -l | grep -i hal

Every line you see is a HAL that has registered with a service manager. The android.hardware.* prefix is the convention that makes them identifiable.

Check yourself#

Sources#