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
SensorFusion is always returning data at the slowest possible sampling rate (5 Hz). batch() is getting called twice, first time with the requested rate and second time with the slowest rate (which overwrites the requested rate). Fix batch call in SensorFusion::activate()
Bug: 12064319
Change-Id: If62f3e514233f69810336fd22b136b4395b667d3
SensorFusion is always returning data at the slowest possible sampling rate (5 Hz). batch() is getting called twice, first time with the requested rate and second time with the slowest rate (which overwrites the requested rate). Fix batch call in SensorFusion::activate()
Bug: 12064319
Change-Id: If62f3e514233f69810336fd22b136b4395b667d3
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
* commit '1f1e576840d5b36a091368abb6fe6610384b6449':
Change API from flush(handle) to flush(). Call flush on all active sensors in the given SensorEventConnection.
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
initialize the system covariance matrix with non-zero
values for the gyro-bias part. this improves the initial
bias estimation speed significantly.
the initial covariance matrix should be small because the drift
changes slowly. the real problem is that we're not starting with
a good estimate of the drift, which this algorithm relies on.
so with this revert, it'll take a while for the drift to be estimated
but it won't be unstable.
Change-Id: Id5584bc114a2390d507643b2451b2650c1b90721
we used to estimate the gyro rate and deduce the period from that
but it turns out this is causing problems.
Bug: 5192288
Change-Id: I8ca826d0e11e488587bcaa1720de99e92b82f191
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
we now use a better quaternion propagation equation
this is especially beneficial for lower gyroscope rates
Change-Id: Ifbf273c8a092a8849ca4fe4b9bca30787e924018
