Custom HAL in AOSP (Hardware Abstraction Layer in Android BSP)

This technical document, Custom HAL in AOSP, explores how to implement and integrate a Custom Hardware Abstraction Layer (HAL) within the Android Open Source Project (AOSP). Using a real-world case study from a marine infotainment system, it breaks down the Android stack - from the Linux kernel and HAL interface to the framework and app layers - showing how custom hardware functionalities can be seamlessly added to Android-based systems.

1. Inception To Adaption
Implementing a
Custom HAL in AOSP
[email protected][phone]

2. Hook - The LED and the Yacht
While working on customer project. When I (and my team) first had to add a HAL for a yacht’s
infotainment system.I thought it would be similar to a car.
But soon we learned that marine infotainment is a whole different system.
No road, no ignition, different safety requirements — yet Android Automotive was still the base.
Android is multi-layer, complex, many places are vendor driven.
So how to start - A simple LED became my test buddy. [phone]
[email protected]

3. AOSP Definition & Purpose: AOSP (Android Open Source Project) is the open-source software
codebase for the Android operating system. Its purpose, initially by Android, Inc. and later under Google,
was to create a free and open mobile platform to foster innovation and competition.
Who Founded AOSP: The project was founded by Andy Rubin, Rich Miner, Nick Sears, and Chris White.
Google acquired the company in 2005 and publicly released AOSP in 2007 through the Open Handset
Alliance, public commercial release on T-Mobile G1 (HTC Dream)
https://www.androidauthority.com/first-android-phone-t-mobile-g1-htc-dream-906362/
Current AOSP Coverage: While a cornerstone for smartphones, AOSP's modular design now underpins
a wide variety of devices. This includes smart TVs (Android TV), smartwatches (Wear OS), and in-car
systems (Android Automotive).
Introduction to AOSP+91-94087 30545
[email protected]

4. AOSP Stack & HAL
Ref - https://siliconsignals.io/building-scalable-embedded-systems-linux-vs-android-bsp-explained/
The Hardware Abstraction Layer (HAL) is the essential interface that standardizes how Android's
software interacts with a device's specific, vendor-defined hardware.+91-94087 30545
[email protected]

5. Linux BSP vs Android BSP - HAL+91-94087 30545
[email protected]

6. When hardware functionality is not covered by default Android HALs
A custom HAL lets the Android OS read real-time data from the yacht's sonar system and display it on a
touchscreen
To support new peripherals or custom hardware modules
A custom HAL integrates an NXP’s SAF775x FM/AM/DAB radio chip into the Android framework.
For OEM-specific enhancements and board bring-up
To handle the pressure sensitivity and detection of an stylus, such as in the Samsung Galaxy Note series.
To standardize access to hardware across apps & frameworks
A custom HAL for a unique fingerprint scanner allows all apps to access its features through a single,
standardized Android Biometric API.
When & Why Do We Need a Custom HAL?[phone]
[email protected]

7. Type of HAL+91-94087 30545
Ref/Pic Courtesy - https://codeinsideout.com/
[email protected]

8. Adding a Custom AIDL HAL [phone]
[email protected]

9. Github Source code - https://github.com/Silicon-Signals/Custom-HAL-Demo-LED
Warning - Code ahead [phone]
[email protected]

10. What it is: The lowest layer, built on the Linux kernel, Kernel = Linux LED subsystem, sysfs nodes
In Implementation:
HAL interacts with the kernel LED driver via /sys/class/leds/sslight/brightness.
Kernel driver updates the LED state when values are written to this sysfs node.
LED driver is part of the standard Linux LED subsystem
Key Point: HAL communicates with these drivers through system calls, keeping hardware access safe and
standardized
Code from repo - vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale
Android Linux Kernel & Drivers+91-94087 30545
[email protected]

11. Why modular design is needed ?
The framework doesn't depend on certain hardware, which makes the system flexible.
Simplifies maintenance and allows easier hardware upgrades.
Benefits of running HAL and Framework in separate processes:
Stability: HAL crashes won’t crash the Framework.
Security: Limits HAL’s access to system resources.
Parallel development: OEMs can implement HAL independently without modifying the Framework.
In Implementation:
Created a custom HAL (sslight) to control board LEDs ; from code - hardware/interfaces
Exposes a simple AIDL method for turning LEDs ON or OFF.
HAL writes to the kernel’s brightness node to change LED state.
Ensures apps control LEDs without touching low-level drivers.
Key Point: HAL makes Android hardware-independent by enforcing standard interfaces
Customized HAL+91-94087 30545
[email protected]

12. What it is: Exposes system services and APIs between apps and HAL..
Key Components:
System Services: Activity Manager, Package Manager, Window Manager, Telephony Manager, Media, Location.
Android Runtime (ART): bridges calls to native components and runs app code.
JNI (Java Native Interface): Bridge for Java framework code to call native C/C++ libraries or HALs
In Our Implementation:
Defined ISslight.aidl interface for controlling LEDs.
Added a service manager to register and expose the LED service.
App calls → Framework easily sends requests to HAL.
App → Framework (Java API) → JNI/AIDL bridge → HAL → LED driver.
Key Point: The framework and runtime make apps hardware-independent, so all hardware access goes through
HAL in a safe and modular way.
Android Frameworks & Runtime Layer+91-94087 30545
[email protected]

13. What it is: The topmost layer where end-user applications run (Dialer, Camera, Contacts, Calendar etc.).
Languages & Tools: Written in Java/Kotlin using the Android SDK.
In Implementation:
Created a test/demo LED control app - packages/apps/LedControl
Calls into sslight service using AIDL.
Allows toggling LED ON/OFF from the UI.
Key Point: Apps are hardware-agnostic because they only see APIs, not hardware details.
In project : In our yacht project, the navigation UI app didn’t care if it was controlling a bilge pump or a LED strip. It
just called a HAL API.
Android App - APK+91-94087 30545
[email protected]

14. After building, HAL artifacts are generated:
Service binary → vendor/bin/hw/android.hardware.sslight-service = Binder service
Shared libraries → Custom HAL
vendor/lib64/android.hardware.sslight-V1-ndk.so
system/lib64/android.hardware.sslight-V1-ndk.so
Configuration files →
VINTF manifest: vendor/etc/vintf/manifest/android.hardware.sslight-service.xml
Init script: vendor/etc/init/android.hardware.sslight-service.rc
At runtime, we can verify processes:
App check → ps -A | grep -i ledcontrol
Service check → ps -A | grep -i sslight
Confirms that the AIDL HAL (sslight) is registered, running, and ready for app requests.
Build & Runtime Outputs+91-94087 30545
[email protected]

15. Visual Demo+91-94087 30545
[email protected]

16. SELinux (SEAndroid) Issues
Challenge: Even if your HAL works in code, SELinux may silently block it.
Yacht case: Custom HAL initially failed — no errors in app, but avc: denied messages in dmesg.
Tip/Trick:
Always check with adb logcat -b all | grep avc for denials.
Use audit2allow to generate candidate SELinux rules, then refine - for your policy file
Keep policies minimal — don’t just grant allow all.
Permissions & Service Registration
Challenge: HAL services must be registered with the right context (hidl/aidl service manager).
Demo LED case: Service started but app couldn’t find it — wrong namespace.
Tip/Trick:
Use lshal or ps -A or service list to verify your HAL is visible.
Ensure versioning is correct (@1.0::ILed/default vs @1.1::ILed/default) or android.hardware.sslight-service
Tips ‘n’ Tricks+91-94087 30545
[email protected]

17. Debugging Across Layers
Challenge: Hard to know whether a bug is in App, Framework, HAL, or Kernel.
Tip/Trick:
Insert ALOGD() or printf() breadcrumbs in HAL code.
Cross-check with kernel logs (dmesg) to see if writes actually hit drivers.
Use strace on HAL process if system calls fail.
Performance & Power Constraints
Challenge: HAL runs in its own process; frequent IPC calls can waste CPU or battery, If HAL sends too many
updates → unnecessary CPU wakeups on idle.
Tip/Trick:
Batch state updates where possible.
Use async callbacks instead of constant polling.
Profile with systrace or Perfetto to catch “hidden” CPU drain.
Tips ‘n’ Tricks (continue . . .)[phone]
[email protected]

18. Key Takeaways
Custom HALs = freedom → add any hardware, scale anywhere.
One clean interface = many possibilities (apps stay hardware-agnostic).
Modularity = stability + security (crash HAL, Android still stands).
From LED → to Cars → to Yachts → same principle, bigger impact.
‘’And the best part? Whether it’s a blinking LED, a car’s HVAC system, or a yacht’s radar — the same HAL principle
applies. That’s power’’[phone]
[email protected]

19. Credits
Jaimin Kalariya - LinageOS maintainer & contributor at Silicon Signals Pvt. Ltd.
Dhaval Shiroya - Android BSP engineer at Silicon Signals Pvt. Ltd.
Ankit Siddhapura - Google AOSP, LinageOS Contributor at Silicon Signals Pvt. Ltd.+91-94087 30545
[email protected]