Passthrough Mode

Introduction

When Android transitioned to Project Treble, forcing all Hardware Abstraction Layers (HALs) into separate vendor processes was a monumental task. To ease this migration and prevent catastrophic performance drops in highly latency-sensitive components (like graphics), Android introduced two modes for HIDL HALs: Binderized and Passthrough.

Same-process Passthrough HAL

Passthrough mode allows the framework client and the vendor HAL implementation to run in the exact same process. Instead of communicating over /dev/hwbinder using IPC, the framework directly loads the vendor's .so (shared object) library into its own memory space using dlopen.

Even though the code runs locally, it is still wrapped in HIDL interfaces. This ensures that the API boundary is strictly respected, even if the process boundary is not.

HIDL Passthrough Wrapper

When a client calls getService() for a passthrough HAL, the system looks for the implementation library (e.g., android.hardware.graphics.mapper@2.0-impl.so). It dynamically loads this library and instantiates the implementation class.

To maintain API compatibility, the build system generates a "Passthrough Wrapper". This wrapper implements the HIDL interface and directly invokes the underlying C++ methods of the loaded library without marshaling the data into a Parcel.

// Retrieving a passthrough HAL (Mapper is always passthrough)
sp<IMapper> mapper = IMapper::getService("default", true /* getStub */);

Passing true to getStub forces the framework to load the library directly rather than querying hwservicemanager for a remote proxy.

When Passthrough is Used

Passthrough mode was heavily utilized during the initial Android 8.0 transition for legacy HALs that had not yet been rewritten to handle IPC overhead. Today, almost all HALs are fully binderized.

The major exception is the Graphics Mapper HAL (android.hardware.graphics.mapper). Because graphics rendering requires mapping and unmapping massive buffers thousands of times per second, the IPC overhead of a binderized HAL is unacceptable. Thus, the Mapper HAL remains passthrough.

Limitations of Passthrough Mode

1. Security: Passthrough HALs execute vendor code directly inside the system or framework processes. A crash in the vendor graphics mapper will crash the entire SurfaceFlinger or system server.
2. Memory Leaks: Because the code shares the same memory space, a memory leak in the vendor library directly degrades the host framework process.
3. Deprecation: Android is actively phasing out passthrough mode for everything except the absolute most critical paths (like graphics mappers), pushing vendors toward fully binderized AIDL HALs.