AIDL vs HIDL - and Why AIDL Won

When Android 8 introduced Project Treble, it needed a way to define stable interfaces between the framework and vendor HAL code. The answer was HIDL (HAL Interface Definition Language). But Android 11 introduced AIDL for HALs, and Android is now migrating everything away from HIDL. Here's what these are and why the migration happened.

What is an IDL?

An Interface Definition Language (IDL) is a way to describe an API contract in a language-neutral way. You write the interface once in .aidl or .hal files, and the build system generates the client/server stubs automatically in C++ and Java. Both sides use these stubs - neither knows the other's internal implementation.

HIDL - HAL Interface Definition Language

HIDL was created specifically for HALs in Android 8. It has its own syntax, its own transport mechanism (hwbinder - a separate Binder domain for HALs), and its own tooling (hidl-gen).

  Android Framework (System partition)
           │
           │  calls via hwbinder
           ▼
  ┌────────────────────────┐
  │   HIDL Interface       │
  │  android.hardware.     │  ← defined in .hal files
  │  camera@2.4::ICamera   │
  └───────────┬────────────┘
              │  implemented by vendor
              ▼
  ┌────────────────────────┐
  │  Vendor HAL Process    │  ← runs in /vendor partition
  │  (camera HAL server)   │
  └────────────────────────┘

AIDL - Android Interface Definition Language

AIDL has existed in Android since the beginning - it was always used for app ↔ system service communication (like binding to a service). In Android 11, AIDL was extended to also work for HAL interfaces, using the same regular Binder that the rest of Android uses.

  Android Framework (System partition)
           │
           │  calls via regular Binder
           ▼
  ┌────────────────────────┐
  │   AIDL Interface       │
  │  android.hardware.     │  ← defined in .aidl files
  │  camera.ICamera        │
  └───────────┬────────────┘
              │  implemented by vendor
              ▼
  ┌────────────────────────┐
  │  Vendor HAL Process    │  ← same Binder domain as framework
  │  (camera HAL server)   │
  └────────────────────────┘

HIDL vs AIDL - Side by Side

• ▸Syntax - HIDL has its own custom syntax; AIDL uses familiar Java-like syntax already known to Android developers
• ▸Transport - HIDL uses hwbinder (a separate Binder domain); AIDL uses the standard Binder that the whole framework already uses
• ▸Versioning - HIDL requires explicit versioning in interface names (camera@2.4); AIDL uses a cleaner single version annotation
• ▸Tooling - HIDL needs hidl-gen; AIDL uses the standard aidl compiler already in the build system
• ▸Language support - HIDL generates only C++ and Java; AIDL generates Rust bindings too (important for security-critical components)
• ▸Stability - both support stable interfaces, but AIDL's stability annotations are simpler to use correctly

Why is Android Migrating to AIDL?

• ▸Simplicity - one IDL language for everything instead of two separate systems
• ▸Rust support - Rust bindings are critical for rewriting security-sensitive HALs in memory-safe code
• ▸Reduced maintenance - HIDL is effectively frozen; no new features will be added
• ▸Unified Binder - having everything on one Binder domain simplifies debugging and profiling
• ▸HIDL is deprecated - Android 14+ strongly discourages new HIDL usage; all new HALs must use AIDL

Rust and AIDL - The New Frontier

• ▸AIDL now generates Rust bindings alongside C++ and Java - this is one of the key reasons AIDL was chosen over HIDL, which had no Rust support at all
• ▸Google is rewriting security-critical components (like Bluetooth and DNS resolvers) in Rust via AIDL. These are areas where memory safety bugs have historically caused CVEs
• ▸Rust and C++ AIDL backends co-exist peacefully - both implement the same .aidl interface contract, so a Rust server can talk to a C++ client and vice versa over Binder without any friction
• ▸Older vendor HALs written in C++ are not going away anytime soon - the expectation is gradual migration, not a rewrite-everything event
• ▸As an AOSP developer, there is no reason to panic. The C++ workflows you know today still work, still compile, and are still the dominant language in vendor codebases. Rust is being introduced at Google's own pace, in areas they control
• ▸The practical advice: keep writing C++ HALs as you do today, but start reading Rust occasionally - the syntax is different but the concepts map well if you know C++. You have time