4e8f561fcd
There's a problem with enabling the transient trigger in the HAL, that is the trigger function exports tree properties - activate, state, and duration which require to be chown'd to system:system during the init process. Hence, the trigger will be now enabled in the init process and the HAL will use the "activate" property to determine if the device has vibrator support via ledtrig-transient. Test: device vibrates with the driver supports ledtrig-transient Change-Id: Ieb195ddc199c6372f5dcf3ca1b2be4fd59724717 Signed-off-by: David Lin <dtwlin@google.com> |
||
---|---|---|
.. | ||
audio | ||
audio_remote_submix | ||
camera | ||
consumerir | ||
fingerprint | ||
gralloc | ||
hwcomposer | ||
input | ||
local_time | ||
nfc | ||
nfc-nci | ||
power | ||
radio | ||
sensors | ||
soundtrigger | ||
thermal | ||
tv_input | ||
usbaudio | ||
usbcamera | ||
vehicle | ||
vibrator | ||
vr | ||
Android.mk | ||
README.android |
Default (and possibly architecture dependents) HAL modules go here. libhardware.so eventually should contain *just* the HAL hub (hardware.c), everything in it should be rewritten as modules. Modules are .so in /system/libs/hw/ and have a well defined naming convention: /system/libs/hw/<*_HARDWARE_MODULE_ID>.<ro.product.board>.so /system/libs/hw/<*_HARDWARE_MODULE_ID>.<ro.board.platform>.so /system/libs/hw/<*_HARDWARE_MODULE_ID>.<ro.arch>.so /system/libs/hw/<*_HARDWARE_MODULE_ID>.default.so They also have a well defined interface which lives in include/hardware/. A module can have several variants: "default", "arch" and "board", and they're loaded in the "board", "arch" and "default" order. The source code for the "board" variant, usually lives under partners/... The source code for "default" and "arch" would usually live under hardware/modules/.