fixed screen flicker on power off - credit CM
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

Conflicts:

	services/sensorservice/SensorDevice.cpp
adding of 4tab slider lockscreen
Fix to help GSM devices with data drop
looks like soemthing got messed up on that last cherry-pick
merged with cm's service/surfaceflinger
Don't enable the light sensor if it's not being used

We want to fully disable the lightsensor when it's not used, for two reasons:
1 - Power savings
2 - Sensors that control the backlight directly need to be disabled when
brightness control is set to manual. Forcibly enabling the sensor when
the screen turns on makes these devices incapable of using manual
brightness.

Change-Id: I64c1114348ff096e0a72b265f6f141d1ecef249c

Fix button backlights that depend on ALS

On a few devices, lighting the buttons when the screen turns on
depends on the lightsensor, regardless of the user preference.
So go back to enabling the sensor whenever the screen turns on, and
enforce the user preference after running through the light settings
once.

Change-Id: I6f036a32315eb7688a9cd11d4bd70dbca1b2fa8b

Conflicts:

	services/java/com/android/server/PowerManagerService.java
undid as cherry-pick with CM messed things up.. will need to do this one by hand
Don't enable the light sensor if it's not being used
We want to fully disable the lightsensor when it's not used, for two reasons:
1 - Power savings
2 - Sensors that control the backlight directly need to be disabled when
brightness control is set to manual. Forcibly enabling the sensor when
the screen turns on makes these devices incapable of using manual
brightness.

Change-Id: I64c1114348ff096e0a72b265f6f141d1ecef249c

Fix button backlights that depend on ALS

On a few devices, lighting the buttons when the screen turns on
depends on the lightsensor, regardless of the user preference.
So go back to enabling the sensor whenever the screen turns on, and
enforce the user preference after running through the light settings
once.

Change-Id: I6f036a32315eb7688a9cd11d4bd70dbca1b2fa8b
Separate configuration of auto-brightness for button/keyboard backlights.

Presently, light-sensor based automatic brightness
(config_autoBrightnessLevels) controls both button and keyboard backlights
in addition to the screen backlight.  Unfortunately auto-brightness for
button/keyboard backlights doesn't work well on devices (e.g., epicmtd)
with neither (i) dimmable button/keyboard backlights (so when they're on,
they're very bright even if the screen backlight is relatively dark) nor
(ii) identifiable surface features on capacitive buttons (so they can't be
found if the backlights are permanently turned off).

For these devices, the non-auto-brightness behavior of button/keyboard
backlights, whereby they turn on during screen-on events and user activity
and timeout-to-off shortly thereafter, is preferable.  Thus, this commit
adds a config option, config_autoBrightnessButtonKeyboard (defaults to
true), that when disabled allows for automatic brightness control of the
screen backlight, but retains the timeout-based behavior for button and
keyboard backlights.

Also addressed is a bug that disables the button and keyboard backlights on
screen unlock, and reenables the backlights on touch events so that
capacitive keys may be located.
frameworks/base: Increase Zygote preload GC threshold to half the heapgrowthlimit.

Increase Zygote preload GC threshold to half the heapgrowthlimit,
to reduce boot up time.

Change-Id: I6ea0f115e5f96836adec5ba9b796f54e6e898643
frameworks/base: Increase the buffer size to hold the whole content of the file.

When we have more cpufreq steps and cpufreq's time_in_state stats file
can grow beyond 256.

This buffer size was not enough because the file has more than 300
characters. So it read part of the file and the parsing failed.
This runs from ActivityManager, so when the ActivityManager dies
framework reboots.Increasing the buffer size will help use to get
the whole file into the buffer.

Change-Id: I3f95dc7534fdaf5e139966c0d1be8d79d6413a0f
patch for hard keyboard - credit Hashcode
changes for Droid 3 RIL swiching, hardware keyboard and legacy GB audio - credit HashCode
Add framework definition to include Torch

Change-Id: I21de929089b06e5022f90c1fab6228a543102a19

Conflicts:

	core/java/android/provider/Settings.java
Part of necessary changes for 2nd generation Moto devices to have
working camera. Rest are in overlay.
more merges