| Name | Commonizibility | Allow opt-out? | Notes |
|---|---|---|---|
| Audio | 100% | Yes | Android default AIDL service should always be built. ALSA audio can be used with either tinyhal or yukawa's HAL, dummy HAL can also be used in case of no audio |
| Display | High | Probably yes | See below |
| Health | 100% | No | Default AIDL health HAL uses kernel sysfs, a cuttlefish implementation also exists for battery-less devices, they need to be merged tho (detect no battery and report fake data) |
| Kernel | 0% | N/A | Each device has its own kernel, completely outside common tree scope |
| Power | 100% | No | Both dummy and libperfmgr HAL can be used, could default to libperfmgr with a dummy config, but requires complicated init scripts as well |
| Security | 50% | Yes | Default software implementations exists, but if a device wants to use its own stack, it needs to opt-out of them |
| Name | Commonizibility | Allow opt-out? | Notes |
|---|---|---|---|
| ClearKey DRM | 100% | No | ClearKey DRM is supported by AOSP |
| Widevine DRM | 100% (with notes) | Yes | A default Widevine service can be provided by common tree for L3. liboemcrypto.so, needed for L1, requires specific Widevine HAL version, so default Widevine service must either be opt-in or opt-out |
| Name | Commonizibility | Allow opt-out? | Notes |
|---|---|---|---|
| Biometrics | 0% | N/A | Forget about it |
| Bluetooth | 100% | No? | android.hardware.bluetooth-service.default implements serial HCI devices, might be enough |
| Camera | 100% | Yes, people might want to use their downstream stack | Can use libcamera |
| GNSS | 100% | No | GNSS devices uses standard NMEA messages, just needs a proper HAL. There's also good progress on open source AGPS implementations |
| IR | 100% (see notes) | No | LIRC API exists, but if IR support is declared, the AIDL IR service MUST be started, so dynamic IR HAL is difficult |
| Lights | 100% | No | Lineage default AIDL lights HAL uses standard sysfs APIs |
| Media (Codec2) | 100% | No | Software codecs will be already available, hardware codecs can be implemented with [email protected] |
| NFC | Low | Yes | NFC usually requires custom HALs, proprietary firmware, etc. |
| RIL | Low | Yes | A ModemManager based HAL exists, unlikely this will work fine |
| Sensors | Low | Yes | Each sensor hardware device's data needs proper treating, needs HALs written from scratch. A IIO based HAL exists, but not all devices uses IIO |
| Thermal | 100% | No | Pixel thermal HAL uses thermal zones, just needs a config |
| USB | Unknown | Yes | ConfigFS is common (we expect newer kernels to use it), but USB and USB gadget HALs aren't common (yet?) |
| Vibrator | 100% | No | Force feedback API (here) and legacy LED vibrator (default AOSP vibrator HIDL) can be used, we can ideally merge those HALs |
| Wi-Fi | 100% | No, see notes | It's complicated, but wpa_supplicant and hostapd don't need forking, so they can be built in common tree. Device trees can then configure it with BoardConfig flags |
Common:
android.hardware.memtrack-service.example, unless the GPU driver can provide memory usage stats (qcom HAL is open source)
For framebuffer:
[email protected]{impl|service}[email protected]+gralloc.default[email protected]
For DRM:
android.hardware.graphics.allocator-service.minigbmmapper.minigbm[email protected]+hwcomposer.drm
Honorable mentions:
Mesa can be used:
libGLES_mesa
Else ANGLE can be used with a Vulkan backend (hardware or software):
libEGL_anglelibGLESv1_CM_anglelibGLESv2_angle
Build your GPU Vulkan HAL (Mesa provides those), else vulkan.pastel for SwiftShader