Android Proximity Sensor - Incorrect value

Question

I've run into an issue trying to create an application that keeps track of Proximity Sensor values. The intent of the application is to record the instantaneous proximity value on regular intervals (say 30 seconds).

Following the API Documentation, the standard listener is created and attached for that type of sensor. However, the value is ALWAYS reported as '5.0' (5cm, the max value of the sensor) even when I cover the sensor with my hand.

However, if I start a DIFFERENT application (that also monitors Proximity sensor values) both applications start to correctly report proximity. When I close the other application (Android Sensor Box) my application reverts to just reporting 5.0 all the time.

I have debugged the application and set a breakpoint in the 'onSensorChanged' event to double-check what SensorEvent object is being passed to the onSensorChanged method, and it's always 5.0

EDIT #2: It doesn't appear to be limited to the Proximity sensor. The Gyroscope sensor behaves in the same manner while Accelerometer and Magnetometer appear to show the correct and up-to-date values. All four are referenced and accessed in the same fashion.

Any ideas?

Answer 1

Well, it turns out that I will once again be answering my own question.

The way the application was structured (and there was a good reason for this) meant that a Listener was registered and the first reported value from the sensor(s) was taken as the reading without continuously accepting new readouts. This works fine for Accelerometer readings but it turned out that some sensors reported their DEFAULT value in this first reading (such as 'FAR' for the proximity sensor or 0.0/0.0/0.0 for the Gyroscope). It was only after 2-3 'onSensorChanged' events that correct values start to be reported.

I am assuming this has something to do with power saving and certain sensors needing time to become 'ready' to report data. I have no idea why the acceptable practice is to fire off a sensorChanged event with incorrect values but that's what appears to be happening.

Nonetheless, the fix for me was to discard the first 2-3 readings (they come in at millisecond intervals anyway) and simply use the fourth one as the more reliable reading.