| 2f3bf13887257abc9943b7e5bf58e9cd8189eb0a |
|
17-Mar-2016 |
Peng Xu <pengxu@google.com> |
Define typical sensor sample rate in native code
Porting typical sensor sample rate (e.g. SENSOR_DELAY_UI)
defined in Java API to native code.
Change-Id: I8b59216415bc952b4e953ca6e8058beb1dd3c645
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| bfbd374cab2ea2a477a3d061fbe336e972e4090d |
|
22-Oct-2015 |
Aniroop Mathur <aniroop.mathur@gmail.com> |
Native: Sensor: For ndk sensor enable request, enable sensor with
SENSOR_DELAY_NORMAL delay instead of 0 delay, by default
In case of one or more sensor applications running in background
(say Auto Rotation, Auto Brightness, some sensor ndk daemon like
panning, etc), which are using the common sensor (say accelerometer)
running at UI delay(66 ms), and then some 3rd party sensor ndk daemon
starts(say Direct Call feature, GPS ndk daemon for correcting latitude
and longitude using sensor data while using navigation, etc), which
enables the same sensor (accelerometer) but does not set the delay,
then that sensor chip will start to generate data at minimum delay
possible because of passing 0 delay value during enable.
Ideally, this is wrong behaviour because none of the sensor-ndk daemon
or android application has requested for minimum delay yet and so sensor
should generate data still at 66ms only. This in turn will make
significant increment in current consumption because of fastest sampling
rate.
Also, as you know, ASensorEventQueue_enableSensor api and
ASensorEventQueue_setEventRate api are not deprecated and is still used
irrespective of HAL 1_3 or latest 1_4. In fact, these are the only two
api currently available for enabling and setting delay. Direct Call,
panning, Smart alert, gps daemon, etc are such examples which uses these
ndk api
Small Code Snippet:
AutoRotation starts:
mSensorManager.registerListener(
listener1, mAccelerometer, SensorManager.SENSOR_DELAY_UI);
AutoBrightness start:
mSensorManager.registerListener(
listener2, mAccelerometer, SensorManager.SENSOR_DELAY_NORMAL);
mSensorManager.registerListener(
listener2, mLight, SensorManager.SENSOR_DELAY_NORMAL);
Panning:
ASensorEventQueue_enableSensor(mSensorEventQueue1, mAccelerometer);
ASensorEventQueue_setEventRate(
mSensorEventQueue1, mAccelerometer, SENSOR_DELAY_UI);
(Here, first 0 delay will be set, but UI delay will override it with
function call setEventRate)
... more possible android-apps/sensor-ndk daemon
So currently, accelerometer is running at 66 ms delay
because DELAY_UI (66ms) is less than DELAY_NORMAL (200ms)
Now, sensor gps ndk daemon starts, enables the sensor but does not set
delay:
ASensorEventQueue_enableSensor(mSensorEventQueue2, mAccelerometer);
--> This call will request for 0ms delay so minimum delay will be set
(say 10ms)
Therefore now, accelerometer will run at 10 ms delay which is wrong
behavior because delay should still be 66 ms ideally. Also, running
sensor at lowest delay unnecessarily increases current consumption.
(Unless requested for minimum delay like in games)
Change-Id: Ib18d0d77f80b2621a204d491c3f61eed9a8b7251
Signed-off-by: Aniroop Mathur <a.mathur@samsung.com>
Signed-off-by: Aniroop Mathur <aniroop.mathur@gmail.com>
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 5c538053346107a8ec704d8769059ab6a23ebeef |
|
29-Jun-2015 |
Aravind Akella <aakella@google.com> |
Enable sensor data injection mode through adb.
Change-Id: I415cf8ff0871fa74babaf9b879c68f210298b472
(cherry picked from commit 841a5926fc9b3f9f0e654ba3aab8e43bea7de7f1)
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 63a0f428230208b9f3601eb7c99a08100c6f3a0b |
|
25-Apr-2015 |
Aravind Akella <aakella@google.com> |
Build fix SensorEventQueue.
Change-Id: I3e6ba031d42bd37067591771f378b7185169ab48
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| a9e6cc387072e25706a6d847a97b02a6f25a918b |
|
17-Apr-2015 |
Aravind Akella <aakella@google.com> |
Enable data injection mode in SensorService.
Change-Id: I0cd32a017235c31c54816e4a357ce3b988350ed6
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| d723bd7669b4fc88dc282d8bf8ba5ecb2849d22f |
|
18-Nov-2014 |
Dan Stoza <stoza@google.com> |
libgui: Enable -Weverything and -Werror
Enables -Weverything and -Werror, with just a few exceptions for
warnings we can't (or shouldn't need to) work around.
Change-Id: I034abec27bf4020d84af60d7acc1939c59986dd6
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| f10c46ef855b6410b20ebd8b1351d4d78d8eca8e |
|
11-Nov-2014 |
Dan Stoza <stoza@google.com> |
Enable clang for libui/libgui/surfaceflinger
Enables clang and C++11 for libui/libgui/surfaceflinger, and
eliminates all compile-time warnings.
Change-Id: Ie237fdb5ae44f2bfcddaa884f9c65ec3f08ae50f
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 8a96955c8e14db40b16164236830fc9506a00872 |
|
29-Sep-2014 |
Aravind Akella <aakella@google.com> |
Fix sockfd leakage in SensorService.
i) Call removeFd() only if the fd in the BitTube has been
previously added to the Looper. Use a flag to determine whether the fd
has been previously added or not.
ii) Increment mPendingFlushEventsToSend after holding a connectionLock.
iii) Store the number of acks that are pending in SensorEventQueue
and send them all at once.
Bug: 17472228
Change-Id: I1ec834fea1112a9cfbd9cddd2198438793698502
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 56ae42613c91f6a6fb0dc3f626daa24666fd18c2 |
|
11-Jul-2014 |
Aravind Akella <aakella@google.com> |
SensorService performance improvements.
i) Send ack for wake_up sensors on the socket connection instead of using Binder RPC.
ii) Cache events per connection in case there are write failures. Compute cache size
from FIFO counts of sensors.
iii) Send FlushCompleteEvent only for apps that explicitly called flush().
Change-Id: I018969736b7794b1b930529586f2294a03ee8667
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 9a844cf78f09953145200b4074d47589257a408c |
|
12-Feb-2014 |
Aravind Akella <aakella@google.com> |
Enable wakeup sensors.
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
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 701166d9f60a6e1149ff568aec0e03f3f3925292 |
|
08-Oct-2013 |
Aravind Akella <aakella@google.com> |
Change API from flush(handle) to flush(). Call flush on all active sensors in the given SensorEventConnection.
Change-Id: I4ef2bec80406c517903ab9782dc9eaf3fa8b7f36
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 90ed3e8d7883d9c80fb8bf11b1c593bd8b2b39d0 |
|
10-Sep-2013 |
Mathias Agopian <mathias@google.com> |
fix a few problems with BitTube
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
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 724d91d778e71c8186399f4955de14b54812b3ed |
|
27-Jun-2013 |
Aravind Akella <aakella@google.com> |
Sensor batching. Changes to the native code.
Bug: 10109508
Change-Id: I7333f3aac76125a8226a4c99c901fb904588df04
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 29267fe8495a74893dfce1bd9eceb6448df7abea |
|
08-May-2012 |
Mathias Agopian <mathias@google.com> |
return errors properly in BitTube and SensorEventQueue
Change-Id: Idf31179f9fcc666e287c7b01b2007431cb60127d
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 7b5be95cb3903087742f1079fe89cddd8abe3696 |
|
03-Apr-2012 |
Mathias Agopian <mathias@google.com> |
use a socketpair instead of a pipe in BitTube
Bug: 6252830
Change-Id: Ia7a7b08409517214136261c05569dc5959a597ab
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| e6f43ddce78d6846af12550ff9193c5c6fe5844b |
|
06-Jan-2012 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGE(_IF) to (IF_)ALOGE(_IF) DO NOT MERGE
See https://android-git.corp.google.com/g/#/c/157220
Bug: 5449033
Change-Id: Ic9c19d30693bd56755f55906127cd6bd7126096c
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 5cae0d0699a169e468fff3e21165f35db12f2cde |
|
21-Oct-2011 |
Mathias Agopian <mathias@google.com> |
Rename SensorChannel to BitTube
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 2ffb24799e579c47a73c992ab567f05c4bf0c962 |
|
17-Sep-2010 |
Mathias Agopian <mathias@google.com> |
Fix typo which causes sensors to fail miserably
Change-Id: Ieca18fc089e2bdf7d049f213836971b54d11cd76
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| aeda9afdba5c28d4d152e3ec3bce74be42949065 |
|
17-Sep-2010 |
Mathias Agopian <mathias@google.com> |
part of fix for [3004226] Cannot end the call - Proximity sensor doesn't work
- In SensorEventQueue, only bail on errors from Looper::loopOnce
- Improve sensor error logging
Change-Id: Ib3cf8d5d9fdac8513a3d753155827e0feeda1662
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 59abe7e0909bf4b7bf7b9601e1e40a05f6d4fd8a |
|
14-Sep-2010 |
Jeff Brown <jeffbrown@google.com> |
Replace epoll() with poll() and rename PollLoop to Looper.
As part of this change, consolidated and cleaned up the Looper API so
that there are fewer distinctions between the NDK and non-NDK declarations
(no need for two callback types, etc.).
Removed the dependence on specific constants from sys/poll.h such as
POLLIN. Instead looper.h defines events like LOOPER_EVENT_INPUT for
the events that it supports. That should help make any future
under-the-hood implementation changes easier.
Fixed a couple of compiler warnings along the way.
Change-Id: I449a7ec780bf061bdd325452f823673e2b39b6ae
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 45e0acb41acf30a1b7592ea7e695d96aca3ccd3b |
|
08-Sep-2010 |
Dianne Hackborn <hackbod@google.com> |
Modify native ALooper to take an explicit ident.
The ALooper API now uses an explicit "identifier" for the integer
that is returned rather than implicitly using the fd. This allows
the APIs that had the fd to be a little more sane.
Change-Id: I8507f535ad484c0bdc4a1bd016d87bb09acd7ff0
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| a48bcf62b6a26f24a0bdd2b44bb39fadce499e92 |
|
30-Jul-2010 |
Mathias Agopian <mathias@google.com> |
Added SensorManager.getMinDelay()
Exposed the new "min delay" sensor property through native and
java sensor apis. This allows the caller to know what is the
maximum rate at which a sensor can return events, or, if a sensor
works in "update" mode (events returned only when the value changes).
Also augmented SensorManager.regusterSensorEvent() so that it can
accept a value in microsecond in addition to the 4 constants already
defined.
Change-Id: If425e9979892666df8c989d7de3c362230fa19e0
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| e3c8234765050023b8a588607f819e8cc41a6363 |
|
22-Jul-2010 |
Mathias Agopian <mathias@google.com> |
propagate sensor event rate properly
Change-Id: I32e67d30e4295285a6827956cc8161b2025d70bc
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| a7352c9f4a6e642c29782b19db5bc0bd98feddc8 |
|
15-Jul-2010 |
Mathias Agopian <mathias@google.com> |
new SensorService
remove old sensor service and implement SensorManager
on top of the new (native) SensorManger API.
Change-Id: Iddb77d498755da3e11646473a44d651f12f40281
/frameworks/native/libs/gui/SensorEventQueue.cpp
|
| 589ce85ee4174829cfedce91b6b2509d2a4002eb |
|
14-Jul-2010 |
Mathias Agopian <mathias@google.com> |
first step at implementing the native sensor support
in this commit:
- implemented the C stub
- implemented the binder interfaces involved
- implemented most of the C++ client side
missing:
- SensorManager cannot connect to the SensorServer yet
(because there is no SensorServer yet)
Change-Id: I75010cbeef31c98d6fa62fd5d388dcef87c2636b
/frameworks/native/libs/gui/SensorEventQueue.cpp
|