SensorService should hold a wakelock till the app reads events from a wakeup sensor. Currently drivers hold a wakelock with a
timeout while delivering events from a wake up sensor like Significant Motion. This hack can be removed now.
Bug: 9774884
Change-Id: If3b5acb99c9cf0cd29012fcfa9d6b04c74133d01
* commit 'ef89f7638c43ce5f73e32d487bf65c3375995e3b':
Add stringType and requiredPermission to sensors, effectively adding permission checking for sensors
* commit 'cf818ebbf07c6a20ef48d71bf82f8d4bdf3a398c':
Add stringType and requiredPermission to sensors, effectively adding permission checking for sensors
* commit '00f4dde1aa88576811bca79bc8242e1fc1edb333':
Add stringType and requiredPermission to sensors, effectively adding permission checking for sensors
* commit 'c57a019e117117c5a76c772970b26cd0f5db8c6a':
Add stringType and requiredPermission to sensors, effectively adding permission checking for sensors
i) Emulate Flush for AOSP Fusion Sesnsors on newer HALs that support batching.
ii) Early return if there are no events for the current SensorEventConnection.
Bug: 11325707, 11376538
Change-Id: Idb856302463649a99d3d5d0c965bb06ba06b8e1d
SensorService is dead locking itself when flush is called on older devices which don't support batching. mConnectionLock is acquired twice.
Change-Id: I5c25585bfb2b396df4b05826a9cba1da7997a3ee
i) SensorService dropping events. Increase SOCKET_BUFFER_SIZE in BitTube ctor.
ii) Call flush before every activate.
iii) Emulate flush for older devices. Add a trivial flush complete event when flush is called.
Bug: 10641596
Change-Id: I30d0f3948e830457143f16e157b6ad81908687ce
BitTube used to send objects one at a time and didn't
handle errors properly.
We now send all the objects in one call, which means they
have to be read as a single batch as well. This changes the
BitTube API.
Update SensorService to the new API.
Also added an API to set the size of the send buffer.
Bug: 10641596
Change-Id: I77c70d35e351fdba0416fae4b7ca3b1d56272251
sensorservice would deadlock if for some reason
a sensor failed to enable.
simplifed the code a bit, and made it behave a little
closer to mr1.1 -- I couldn't convince myself that
some changes in how locks were used were correct.
Bug: 9794362
Change-Id: I6110f5dbb67e543f1c71d127de2299232badb36a
it now displays the reported trigger mode properly, as well as
the number and type of the last received data
Change-Id: I2ff64b32ab71f1332bc2e09671c8c02bb9550490
1) "google" sensors are now reporting AOSP as the vendor string
2) don't expose the system's sensor fusion if the HAL provides it
3) use uncalibrated gyro if availble for the system's sensor fusion
Change-Id: I25140436cdb29d55e39fd6fbbf8c44a410a83d5c
Auto disabled sensors get auto disabled after trigger.
An activation after this wasn't working because the
state was not being reset.
b/8609561
Change-Id: If72c9f27345e91671d7ad0a7a066f6dc3d255b78
1. Some sensors can wake up the AP. Add wakelocks.
2. Handle backward compatibility for rotation vector
heading accuracy.
3. Cleanup auto disabled sensors.
4. Fix race condition between enable and dispatch.
Change-Id: I39dddf12e208d83cd288201986ee994312555820
until now we were tracking when a sensors was
physically enabled or disabled and we were reporting
that to the BattaryService.
this wasn incorrect because we could have several different
apps enabling the same sensor, so the accounting by the
battery service would be incorrect in that case (depending
on the order in which these apps disabled said sensor).
BatteryService tracks sensors per uid, however SensorService
does this per binder connection, so we could have several
binder connections for the same uid, to solve this we keep
a list of sensor/uid -> count, which is the bulk of this
change.
Bug: 6661604
Change-Id: I561c198c42ba1736a8671bdacda4c76d72b9dd6f
It shouldn't have caused much harm though.
Also log a warning when enabling a sensor
for a connection that is already enabled.
Change-Id: Ia4a052381e79183cd4cb1bedc7ba08e5228d7a38
if debug.sensors is true, extra debugging
sensors are enabled and HAL provided sensor fusion
is disabled
Change-Id: I9b093424edb8c5363d1337237cdf6abe4ab266f9
some sensor HALs don't handle EINTR, make sure to catch it in the
sensorservice.
also if we ever encounter an error that we can't handle, we abort
which will restart us (or the whole system process if we're running
in it)
Bug: 5511741
Change-Id: I7051882b06980f778736b53d6cd021a99b5ca8d2
Requested rate will be clamped to the minimum rate and then
to 1ms. Previously we would return an error if a lower
rate was asked. The SensorManager documentation wording
allows this change.
We do this to get more consistancy between all the sensor
drivers / HALs
Change-Id: I199f76486fb76ccbb11e7280460a03726c767e84
When the app requests "fastest", the java layer encodes this as a
delay of 0. SensorService was passing this unchanged to the HAL.
However the HAL is required to reject delays lower that the
advertised lower delay.
Change-Id: I92be77acd3af62ffeb49e4b31e24ddcd203510e2
This is intended to absorb the cost of the IPC
to the permission controller.
Cached permission checks cost about 3us, while
full blown ones are two orders of magnitude slower.
CAVEAT: PermissionCache can only handle system
permissions safely for now, because the cache is
not purged upon global permission changes.
Change-Id: I8b8a5e71e191e3c01e8f792f253c379190eee62e
when we do our own sensor fusion, we also export an
improved orientation sensor and hide the HAL sensor.
The fused orientation sensor is much more precise, fast
and smooth.
Change-Id: I0ea843b47ad9d12f6b22cce51f8629852d423126
also use correct time propagation equation
disable the fused sensors when gyro is not present since
they were unusable in practice.
Change-Id: Iad797425784e67dc6c5690e97c71c583418cc5b5
Add support for 9-axis gravity and linear-acceleration sensors
virtual orientation sensor using 9-axis fusion
Change-Id: I6717539373fce781c10e97b6fa59f68a831a592f
