I'm trying to create an app that utilizes the proximity sensor in most Android phones. But, since I can't really emulate getting my face close to an emulator, I'm debugging on my Nexus 7. Unfortunately, nothing is happening in regards to the proximity sensor.
So, I guess my question can be answered pretty easily, but, does the Nexus 7 even have a proximity sensor? If it does I'll post some code, but I have a feeling that may be my problem...
Thanks!
According to the specs, the Nexus 7 doesn't have a proximity sensor. And it makes sense to not have one, as you're never going to talk on it.
Felix is right, there is no proximity sensor like on the nexus 4.
There is a magnetic sensor Between the z and mic button on the standard keyboard when in upright portrait mode. It behaves like a shmitt trigger hall effect sensor.
Finally, I have noticed that touches can be sensed on the capacitive touchscreen even without physical contact. Experimentation may yield interesting and innovative results. Or a loss of hair.
Best of luck.
Related
I used to extract accelerometer data by android SDK on Samsung Galaxy S4,
and I encounter a strange problem when I change platform to HTC One M8.
Here is the statement about the experiment:
Once I move the device from place A to place B straight(negative direction of device), I will read the accelerometer data and compute the displacement between A and B.
The curve of acceleromter data on S4 is correct.
It contains two pick with different sign and the shape like 'S' lie on the floor.
But when I use M8, it give me the curve which is wrong obviously. it looks like 'W'
P.S. The motion and program of two are totally the same.
Can anyone give me some reason to the difference?
Is the g-sensor on M8 is the problem?
I'm really stuck on it.
thanks.
From what I understand from trying to use the Moves app, this is due to lack of support of the accelerometer when the device's display is off.
I am looking for a way to change that now and if I find something I will update here.
update:
It seems this could just be due to new hardware not being supported yet. This quote leads me to believe that "...are the low-powered, always listening "Smart Sensors." Accelerometers are nothing new, but HTC's can be used by apps all day long without significant drain on the the battery (as they don't fire up the processor etc). As HTC's opened up the API for these -- dubbed HTC's Smart Sensor Hub -- app developers will be able to hook into this information directly."
I have got a small application that uses compass readings on my device (Xperia Neo V). When testing it, I got very satisfying results while pointing the desired direction. But I tested it on a Samsung Galaxy S3, and I run the same application on my neo V at the same time, the two devices did not show exactly the same direction. There was a drift about 10 degrees.
So, as an electronical engineer I know that different digital compass sensors may give different values due to design, but I coulnd't find an efficient solution to that yet. Any Ideas?
I would try some experiments using rotations in different direction on both devices in the same environment to find any correlation on the results. Possibly there's an offset that should be removed. A real pure compass device could help to estimate the noise level.
[Edit: Removed all mention of Android version - the issue is present on all versions of android]
Background: When the screen is off, many Android phones do not provide updates to applications of Accelerometer readings by calling onSensorChanged() when the screen is off. This behavior is discussed on S.O. and is further documented here
http://code.google.com/p/android/issues/detail?id=3708
On some phones (Nexus S, Droid X2, ...) accelerometer values are only provided when there is a significant change in value. Sitting still on a table, for example, there might be one or zero updates per minute
In order to produce code that is robust across phone models, how am I to distinguish between a lack of update events per screen off, vs. lack of updates per non-movement? Should I maintain a database of phone models?
This will be hard to detect. Android's API provides a way to control the Wake Lock. But manufacturers have done a TERRIBLE job of implementing this into the OS on their side. Just TERRIBLE. You would need to grab a PARTIAL_WAKE_LOCK to keep the phones CPU running when the screen is turned off.
However not all devices use this and will not respond - some half/half respond - and some respond great.
After reading the comments above I can tell you the majority of devices with 2.3+ I have used still do not implement the partial wake lock still.
I personally would not rely on something the manufacturer controls because the market is SO fragmented. I would try to find a way to get the functionality I'm looking for with a different solution.
Hope this helps.
I've been looking for a solution for this problem for two days now. But still didn't find anything useful.
At this post here, by Bruno Albuquerque there's something that could help with motorola phones but it's not generic.
I believe #jjNford is right about manufactures have a finger on that, can you post any info about that?
Here is a bug report about that dated from 2009
Does anybody own an LG Optimus S and seen a value for Sensor.accuracy that wasn't 0 (Sensor.SENSOR_STATUS_UNRELIABLE)? We apparently need to test accuracy of the sensor events we are getting, but on my phone the accuracy is always 0 and wanted to see if it was a phone wide issue or if mine is busted or something.
Thanks.
If you look to part lists of your phone, you will find that accelerometers built in are far away from reliable - so there is always a lot of noise and little accuracy. Chips used in HTC Hero provide deliver 8 bit value for +/- 8G
(hope this helps, even it is not LG specific)
I have noticed that by shaking or tapping the phone (an SE Xperia x10 mini) several times recalibrates the magnetometer. Is there any way of doing this software-wise in a more controlled way?
I don't think so. It seems some sort of "hardware reset": when the magnetometer has been confused by a magnetic field (a loudspeaker is usually enough) it requires physical movement in order to return to a "plain state".