sensors: Add support for old libsensors HAL

Enable with TARGET_USES_OLD_LIBSENSORS_HAL:=true

Change-Id: Ib430d8305148f337dd111c80be60ddd151ea5926

sensors: Improve support for old libsensors HAL

Some devices (harmony, at least) claim to support the nuSensors
SENSORS_HARDWARE_POLL, which was breaking the compatibility
check. This removes that check from runtime and makes it
exclusively a compile-time option..

Change-Id: Ide4262e5dec296d96aa896d676a06985fe09aef1

sensors: Fix sensorId/sensorType logic in back-compat layer

As it was, the code was only working on devices where the ID matched
the the sensorType. This isn't necessarily true on every device (and
definititely isn't on some)

Change-Id: I70a5d827c5a6406b5edacc334705edb43e6f5638

sensors: Simplify the data translation in the back-compat hook

Since the sensor data comes in a union, we don't need to do a copy
for every possible entry, we just need one per type. This cuts us
down from 6 data copies on every poll to just 2.

Change-Id: I755f3018ad38be1b7fa04528143507204b4df605

sensors: More compatibility fixes

Some of the old HAL "magic values" aren't magic anymore, so discard
them instead of trying to react like the pre-2.3 implementation.

This had the potential of causing infinite loops on some libsensors (it
was doing it on yamaha's)

Change-Id: Id792faa6a454428040ae2973e386f3a25c904c8e

sensors: Add handle-to-type mapping in back-compat layer

The result of the old API data_poll is an int, which should represent
a handle to the actualy sensor. That handle must be mapped to the sensor
type, which is required by the new API.

I was wrongly assuming the handle and the type were the same, and that
isn't necessarily true; the only reason this was working is because the
java client API appears to be still doing its own handle-to-type mapping
and mostly ignoring the type value set at the native layer

Change-Id: Ibe6209b91cf96aa885a05d6091155ee7ef929211

sensors: Add workaround for Foxconn's broken sensor data

FIH has a tendency to add in-kernel "shortcuts" for stuff that's usually
controlled in userspace, and disabling the screen+backlight on proximity
was one of those. That implementation is, however, buggy, and on top of that
it's colliding with the standard userspace implementation.

This should be corrected at the sensors HAL, but reimplementing that
has been a work-in-progress for quite some time now and still isn't functional.
So, for now, toggle a workaround with TARGET_HAS_FOXCONN_SENSORS, and
convert the data into the kind of values the framework expects.

Change-Id: Ib974af729ce0511668c835b9078831330b874a1f

Add TARGET_SENSORS_NO_OPEN_CHECK for betelgeuse (Folio100) support

sensors.tegra.so on betelgeuse return -22 on both sensors_control_open,
sensors_data_open, but sensors are OK after those two calls.

Change-Id: Iabe14f9ed26ff182041f447cf278408ada62ef81

sensors: Fix ALS and PS lag on back-compat layer

These 2 sensors only report values on change,
instead of continuously generating samples at 'setDelay'
intervals like most others. If only these 2 (or any one of
them is enabled), we can't wait for the usual 64 samples
to be taken before reporting them to the framework, since
that'll make them visibly laggy.

This patch causes any sample from these sensors to trigger
an immediate report to the client.

Change-Id: Id5932376858c30323bff07ac4b38856dc200d074

sensors: Add dummy light sensor for p990/p999

This is necessary for the rest of userspace to recognize its existence
and toggle it for auto-brightness. It doesn't generate actual light
values, though; all backlight adjustments are made in-kernel.

Change-Id: I0e546b4740720bd34d1e1d85a96b295fcc697106

sensors: Allow target to override max range of proximity sensor

If a proximity sensor rarely or never reaches its maxRange, the
device will frequently lock up after the sensor is triggered (by
a call, for example), since it'll get stuck in the "active" state.

Set TARGET_PROXIMITY_SENSOR_LIMIT := <value> with the distance
from which the sensor will turn off to override those cases

Change-Id: I31fa2e5b9bd40ed6d80a1d5b0c147ed265f94c3a

Change-Id: Ib430d8305148f337dd111c80be60ddd151ea5926a