| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: Ied7b779f39e71d041791729f7355b052b63903c5
|
|\
| |
| |
| |
| | |
* commit 'cdbf28b3f7f5327f4cb0eb95b8326bf4c24c87ba':
native frameworks: 64-bit compile issues
|
| |
| |
| |
| |
| |
| |
| | |
- Fix format (print/scanf)
- Suppress unused argument warning messages (bonus)
Change-Id: I05c7724d2aba6da1e82a86000e11f3a8fef4e728
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
(cherry picked from commit 88509090387eeb400771a786171866710cca230c)
|
|/
|
|
|
| |
Bug: 11822806
Change-Id: I1402d6684ed71ed413aef6a7be3aad945b331ec2
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
in the given SensorEventConnection.
Change-Id: I4ef2bec80406c517903ab9782dc9eaf3fa8b7f36
|
|\
| |
| |
| | |
into klp-dev
|
| |
| |
| |
| |
| | |
Bug: 10786801
Change-Id: I7b938bc583a303a30237c3d93b5accbf64cc90b5
|
|/
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Bug: 10109508
Change-Id: I7333f3aac76125a8226a4c99c901fb904588df04
|
|
|
|
| |
Change-Id: Ic65434a26c7fed1699abf0851fec6faa40e09c0c
|
|
|
|
|
|
| |
I changed the name of the service, this needs to follow.
Change-Id: Id8e346cee9d75cfe142cd43f6aea43302878b6dc
|
|\
| |
| |
| | |
Change-Id: Ie1769be863ee2d411eae451907a928db57882e14
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| | |
getSensorType() ran in O(n) instead of O(1). fix that.
Change-Id: Idcf29e46fc34db32604a0d8e5a9156486783b74f
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
| |
we only export the main entry-point.
this saves about 150KB.
Change-Id: I55eb2b6705386fdfa43860deb62f9cdd2a0982aa
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Bug: 8580410
Change-Id: I2ca4fa00dde0b574df3619134836bcb9315bd506
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: Id4865f3cd27a95acdbbfdff1f2bb4123f312a13b
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: Ia2e2c9531715fc2bd5b51c4dc58389e01abfe7e6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) there was a typo when computing the system covariance
a term in dT^3 was ommitted; the impact was was very limited
because of how small this term is.
2) initialize the system covariance matrix with non-zero
values for the gyro-bias part. this improves the initial
bias estimation speed significantly.
3) added comments here and there
Change-Id: I4328c9cca73e089889d5e74b9fda99d7831762dc
|
|
|
|
|
| |
Bug: 6580560
Change-Id: Icf6cafbca09174515a964a7cd69d8cc589ad52de
|
|
|
|
|
| |
Bug: 6576732
Change-Id: If0f2fb0d0c35b932fb77cd262e676042145b28f9
|
|
|
|
| |
Change-Id: I041c64616d88ed1abb5efc90ed9eb0d9baeb4832
|
|
|
|
|
| |
Bug: 6252830
Change-Id: I363cc7e9f73a5b7d8bbccee312c6d8938c84e99a
|
|
|
|
|
|
|
| |
See https://android-git.corp.google.com/g/#/c/157220
Bug: 5449033
Change-Id: Ic9c19d30693bd56755f55906127cd6bd7126096c
|
|
|
|
|
|
|
| |
See https://android-git.corp.google.com/g/157065
Bug: 5449033
Change-Id: I00a4b904f9449e6f93b7fd35eac28640d7929e69
|
|
|
|
|
|
|
| |
See https://android-git.corp.google.com/g/156801
Bug: 5449033
Change-Id: Ib08fe86d23db91ee153e9f91a99a35c42b9208ea
|
|
|
|
|
|
|
| |
See https://android-git.corp.google.com/g/156016
Bug: 5449033
Change-Id: I4c4e33bb9df3e39e11cd985e193e6fbab4635298
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Change-Id: I8b53d5cab884c3aca16d95df5fbf288368d52e8b
|
|
|
|
| |
Change-Id: I6248b6f1f001fedec1bddcddfcd2b381d9bb4bf4
|
|
|
|
| |
Change-Id: I6b6f75373f4ac28f98dea6a6f1c2567a6aa02243
|
|
|
|
| |
Change-Id: I18e5b72d02bf5420c14334d3a03f18fa40572d31
|
|
|
|
| |
Change-Id: I51186e12fb9b2316e3671e3908174f4495df89a0
|