18082bd61f
Library to handle dynamic sensor connection. There are two way to use
this: as hal extension or standalone hal module.
In hal extension mode: add libdynamic_sensor_ext in dependency of hal,
instantiate DynamicSensorManager with appropriate parameters. Then
for all sensor requests, if the handle is owned by dynamic sensor
manager, forward the request.
In standalone mode, add sensor.dynamic_sensor_hal into device make
file. Usually, this also means multihal is necessary. Add
sensor.dynamic_sensor_hal into multihal configuration file.
A dummy sensor module is included for testing.
Test: tested with cts dynamics sensor related test and demo app.
also verified sensor basic operation with sensor logger.
Change-Id: I16612935fc21b06c173aca875401ece37c6bde01
|
||
|---|---|---|
| .. | ||
| 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 /vendor/lib/hw/ and have a well defined naming
convention:
/vendor/lib/hw/<*_HARDWARE_MODULE_ID>.<ro.product.board>.so
/vendor/lib/hw/<*_HARDWARE_MODULE_ID>.<ro.board.platform>.so
/vendor/lib/hw/<*_HARDWARE_MODULE_ID>.<ro.arch>.so
/vendor/lib/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/.