What uses /system/lib/hw/sensors.*.so on Android (and where’s the source)?

Question

My phone’s Android has under /system/lib/hw the following files among others:

1. sensors.exynos4.so
2. sensors.smdk4210.so

Those dynamic libraries are somewhere in the chain for sensors like compass, gyroscope and ambient light.

The first file (sensors.exynos4.so) comes from the the distribution itself (running CyanogenMod 10.1 for i9100), the second (sensors.smdk4210.so) is what I fished out of the stock ROM for my phone (SHW-M250S, “Korean S2”, a variant of the i9100) and copied it there.

Question1: What is using those files?

Doing an ldd (actually a readelf or objdump) over all binaries and libraries in the system did not reveal any users of those files. My conclusion: someone has to load them like plugins during runtime after dynamic linking! But who/what? (source code file name or link to a code browser, please)

The users of those libraries switched from the first to the second without any configuration (after I placed it there). I would like to dig into this mystery.

Question2: Where is the source of those files?

The files contain (at least) the configuration of the sensors (like it’s positioning on the board, value ranges and steps). I want to generate a correct one for my phone. If I have the source of both, it would be easy to do so. – With only the CyanogenMod version, I can at least guess the necessary corrections.

Notes:

1. No guesswork answers.
2. If part of your answer is “binary”:
   1. point me to the blobs in the CyanogenMod source or the script that pulls them.
   2. follow the chain to the first open source library/program which uses them.
3. The questions are not really device specific. – Answer with any device in mind, the situation should be similar (AOSP, AOKP, CyanogenMod, ...).

Answer 1

They are binary blobs.

Has the sensors.exynos4.so and other proprietary blobs https://github.com/chris41g/proprietary_samsung_epic4gtouch/tree/master/proprietary/lib/hw

The blobs can be pulled from a running device with the extract-files script which reads a list of the proprietary files from proprietary-files.txt in the project for whatever device you are building CM for.

Try googling the files maybe or looking through the CM tree or their wiki.

The HAL is the Hardware Abstraction Layer is the interface that is used to get sensor data from the kernel/device drivers back to userspace. Found this pdf which discussed building the Android HAL but for a different device and the output described there is

After having successfully downloaded and compiled the Android sources, the user can compile and add/substitute the sensor HAL library.To do this, copy the sensor HAL library folder in the android sources path, usually located in:
[Root Android Sources]/vendor/[vendor name]/[boardname]/

Before the build operation of the library, the user must initialize the Android environment:
[Root Android Sources]$ source build/envsetup.sh
[Root Android Sources]$ lunch [target board]

It is now possible to build the library; just launch the “mm” command in the HAL folder. The result of this process is a dynamic library located in:
[Root Android Sources]/out/target/product/[board name]/system/lib/hw/sensors.[board name].so

In the case of the sensors, the SensorService loads the HAL so it can talk to the sensors.

HAL
Building HAL

Update:

Did some more digging around my CM tree device/samsung/i9100 contains an Android.mk file that builds sensors.exynos4.so. The .mk file specifieds the module as
LOCAL_MODULE := sensors.$(TARGET_BOARD_PLATFORM) which is set in device/samsung/galaxys2-common/BoardCommonConfig.mk.

There is source in device/samsung/i9100/libsensors for this device. Looking at device/samsung/i9100g however there is no libsensors and that device requires running the CM scripts to pull the blob from a running device so the availability of source still varies based on device.

Also just an observation that the BoardConfig sets some values to smdk4210.

Answer 2

I can’t answer yet what uses those files, but the source for sensors.*.so is nice to navigate to in CyanogenMod:

Each supported device has a wiki entry which points to the github repo (e.g. i9100 source). There you find additional repositories in cm.dependencies which together cover what you need to build CM for the device in question (e.g. the kernel, common files shared among a group of devices, ...).

In case of the i9100, we can stay in the root repository. In libsensors/Android.mk we see that sensors.<ro.product.board>.so is produced by the files in this directory. The source is all there (for the i9100 device), except libakm.so (binary, according to ../proprietary-files.txt), which is dlopen()ed in AkmSensors.cpp. libakm.so is used for enabling and disabling some sensors, but also creates /dev/input/eventX, a virtual input device reflecting three of the sensors available (compass, acceleration, orientation). (I don’t know how the kernel “runs” virtual devices.)

(sensors.*.so is the Hardware Abstraction Layer. – For the i9100 it handles some /dev/input/event* devices. I didn’t check the kernel for details of those...)