The Two-Language Problem
Project Treble saved Android updates by separating the framework from vendor implementations. To guarantee this strict boundary, Google created HIDL. The framework would use standard AIDL internally, while all hardware communication would happen over HIDL.
This architectural decision created a massive split in the platform. Engineers had to master two completely distinct interface definition languages. The duplication extended deep into the operating system architecture.
A framework component talking to another framework component used the standard /dev/binder kernel driver. That same framework component talking to a hardware abstraction layer had to switch contexts and talk over a separate /dev/hwbinder driver. This required running two separate service managers in the background. The memory footprint grew, and the kernel overhead doubled.
Maintaining parallel IPC infrastructures became an enormous tax on the ecosystem. The platform needed a way to return to a single language without breaking the strict vendor boundaries that Treble originally established.
The Rise of Stable AIDL
Google could not simply revert to using traditional AIDL for hardware interfaces. Traditional AIDL lacked the strict versioning guarantees required to keep vendor code compatible with future framework updates. If a framework developer changed an AIDL interface, a vendor implementation using an older version would crash.
Android 11 solved this by introducing Stable AIDL. This extension to the language added cryptographic hashing and strict backward compatibility checks during the platform build process.
When a developer defines a Stable AIDL interface, the build system freezes its structure. Any future modifications to that interface must be purely additive. If a developer attempts to remove a method or change a parameter type, the build fails immediately. The generated code also includes version hashes that both the framework and vendor sides verify during connection.
With these safety mechanisms in place, AIDL became capable of serving as the single IPC language for the entire Android stack. The platform gained a reliable path to deprecate HIDL entirely and simplify the overall architecture.
Architectural Wins of Unification
Ripping out an established language requires massive technical justification beyond just developer convenience. The platform needed to reclaim resources to justify the migration effort.
Transitioning to Stable AIDL eliminates the parallel binder infrastructure. All inter-process communication unifies under a single channel. This direct consolidation reduces kernel memory allocation and drops an entire background daemon.
The following flowchart contrasts the system architecture before and after the migration. It highlights the reduction in kernel drivers and system processes. Notice how the framework process no longer maintains dual communication channels in the unified model.
Under the old model, a framework process had to maintain connections to both the standard service manager and the hardware service manager. The new model routes everything through a single /dev/binder driver. Instead of running parallel subsystems, the OS drops the /dev/hwbinder node completely.
Replacing the rigid major and minor versioning scheme of HIDL was another significant win. Stable AIDL uses a flat, incremental versioning model that is much easier for vendors to maintain across release cycles.
The Migration Enforcer
Vendors have little incentive to rewrite perfectly functional HIDL code just to clean up the architecture. The platform needed a mechanism to force adoption over time.
Google uses the Vendor Test Suite and the system compatibility matrix to enforce the deprecation strategy. Existing HIDL interfaces are permanently frozen. If a vendor wants to support a newly introduced Android capability, they cannot simply bump the version of their existing HIDL interface.
Developers are forced to rewrite that specific interface in Stable AIDL. Eventually, older HIDL interfaces are stripped from the compatibility matrix entirely. When a device attempts to launch using those removed interfaces, it fails the test suite and cannot ship with Google services.
Such policies create a gradual but inevitable gravity toward full unification. Over a few release cycles, legacy code ages out, and the ecosystem naturally converges on a single language.
The shift from HIDL to Stable AIDL represents a major architectural correction in modern Android. It removes a redundant communication layer, reclaims system resources, and gives developers a single toolchain to master.
Now that we understand why the platform is moving to Stable AIDL, we need to look at how these interfaces actually get registered and discovered. How does a framework service find the exact hardware interface it needs at runtime?