I am currently working on an app that utilizes the light sensors to perform a task in my service. I used the examples from this site as my base:
Android Light Sensor
The sensors work perfectly when my tablet is plugged into the computer to debug. However, if I run the same code without it being plugged in, the response is super slow, and some times never triggers at all.
Can anyone suggest why the performance is hindered when the device is by itself?
EDIT:
I SHOULD HAVE NOTED THAT I AM TRYING TO READ THE SENSOR WITH THE DEVICE OFF. I FOUND THAT THE PROBLEM WAS THAT THE SENSOR WAS SHUTTING DOWN WHEN THE DEVICE SLEPT. PLEASE SEE MY ANSWER BELOW.
Thanks,
josh
Sometimes this is just a device issue, many have been reported as acting slow to light/proximity sensors. As far as the anomaly of the sensors responding normally when it is plugged in; maybe your device sensors simply respond faster when there is a power source.
I'd say look through your options with changing the rate
In:
https://developer.android.com/reference/android/hardware/SensorManager.html
rate rate of events. This is only a hint to the system. events may be received faster or slower than the specified rate. Usually events
are received faster. The value must be one of SENSOR_DELAY_NORMAL,
SENSOR_DELAY_UI, SENSOR_DELAY_GAME, or SENSOR_DELAY_FASTEST.
So I would imagine adding SENSOR_DELAY_FASTEST may help you.
Also, I refer you to Android SENSOR_DELAY_FASTEST isn't fast enough post.
I found that the cause of the trouble was the device shutting the CPU down, which resulted in delay or non-reading of the light sensor.
Adding a partial wake lock did fix the problem, but at the cost of high battery usage. If anyone has any suggestions as to how I can continue monitoring the light sensor with the device off without the Wake Lock I would greatly appreciate it.
Related
I am developing an app that I would like to have constantly monitor accelerometer sensor data, even when the screen is off, but I would also like my battery to last longer than 5 hours :/ The most obvious thing of course is to set the sampling rate very low. I have tried to register the accelerometer with both SENSOR_DELAY_NORMAL and with a microsecond value of 1000000 (once per second) using
senSensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
senAccelerometer = senSensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
senSensorManager.registerListener(this, senAccelerometer, SensorManager.SENSOR_DELAY_NORMAL);
but the Android OS quickly (after I jiggle the phone for a couple seconds) decides to override these suggested sampling rates and starts sending my app non-stop accelerometer sensor events at about 100/second, even when I turn the screen off. Needless to say, this is not good for the battery life.
What I have tried for now is a bit of a hack, and I'm wondering if 1. there is a better, Android appoved way to do it, and 2. if what I've done is going to not actually work the way that I want it to. My current solution is to immediate unregister the accelerometer after the first reading (from within the listener callback), record the time of unregistering and then to have a separate timer loop that re-registers the accelerometer listener after a half-second has passed. This seems to work, but I don't know if it's going to cause problems on some devices, or maybe the registerListener function itself drains batteries on some devices? Any advice from anybody else who has made a non-battery-draining always-on background accelerometer listener would be greatly appreciated. Thanks.
EDIT 9/7/2016:
The hack that I described above does seem to work and does seem to save significantly on battery, as long as I slow down the sampling speed to about 0.5 or 1.0 seconds. If I have any more experience, good or bad, with this technique I'll let you all know. (If it matters, I'm testing this on a Note 4, Android 5.1.1) (also added a bit more explanatory code up above)
You might want to look at how it's handled in this project:
https://github.com/alanszlosek/androidstudio-accelerometer-gps/blob/master/app/src/main/java/com/alanszlosek/whenmoving/MainService.java
Seems to be using alarms to schedule logging. Bit of a different situation with even lower sampling frequency, so I'm not sure what method is more efficient.
Would it be possible for you to stick your logger code up on github or somewhere? I'm trying to do accelerometer tracking for a grant project and having trouble getting the services and wakelocks to play well together.
It is a well known issue that many Android phones switch off the accelerometer when the screen goes off. However something seems to have changed with Android Fit (the app). Fit keeps counting steps even when the screen goes off. If Fit is installed, then events are raised for step counting within the Fit environment and I am able to capture them using
Fitness.SensorsApi.findDataSources(mClient, new DataSourcesRequest.Builder()
.setDataTypes(DataType.TYPE_STEP_COUNT_CUMULATIVE)
I have tested this on a Samsung S4 and on a Oneplus One and in both cases the steps are counted.
How do they do that? What Android classes do they use?
My understanding is that the available method introduced since Kitkat is to implement a SensorEventListener. For example theelfismike provides code that implements this. However on many phones the step counting stops when the screen goes off. Interestingly the counting does not seem to stop if the Google Fit app is installed (hence I guess they keep the accelerometer on).
Am I missing something? Is the functionality of keeping counting steps after screen off available to the mortal programmers?
Thanks!
As Ilja said, your code runs even after the screen gets turned off. But in this case I guess we need a little different answer.
They definitely use a Service that keeps a wakelock and they query the sensors for data. Important part here is holding the wakelock - you have to prevent the device from going into sleep during lifetime of your service - if you don't want to miss some data.
But this approach will be drain the battery really fast, because in order to detect steps you need to process quite a lot of data from sensors.
Thats why there is sensor batching. That allows you to get continuous sensor data even without keeping the device awake. It basically stores the sensor events in a hw based queue right in the chip itself and only sends them to your app (service,..) at predefined intervals in batches. This allows you to do a 24/7 monitoring without draining the battery significantly. Please note that only supported chipsets can do that (you can find details in Android docs), in case of older phones you need to fallback to the hideous wakelock keeping method in order to get your data.
You can also just use Google Fit APIs, but this would only work when there're both Google Fit + Google Play Services installed on the device with monitoring turned on.
Every normal Thread is keep on working when the screen goes off or when the Activity lost its focus...but when the activity gets killed then all thread are killed...
However you can use services for longrunning tasks like asking the accelerometer for example
I am running a simple application that receives
and displays the values of Bluetooth Low Energy
advertisement packets in real time.
The Glass heats up in about 5 minutes and touch
commands stop working. The Glass is not super
hot, but warmer than feels comfortable.
Commenting out the Bluetooth stuff reduces the
heating considerably.
How can I make this application workable on the
Glass?
Without seeing the exact code you're using it is difficult to diagnose, but from your description we might be able to make a guess.
It sounds like you're using BluetoothAdapter.startLeScan() without setting up a timeout to stop the scan, and then scanning for an extended period of time. The documentation at http://developer.android.com/guide/topics/connectivity/bluetooth-le.html#find points out:
Because scanning is battery-intensive, you should observe the
following guidelines:
As soon as you find the desired device, stop scanning.
Never scan on a
loop, and set a time limit on your scan. A device that was previously
available may have moved out of range, and continuing to scan drains
the battery.
Battery drains typically correspond to Glass overheating.
There isn't a lot you can do to solve the problem, but it may involve changing how you think about what you're doing.
If you're doing this in immersion mode, you may want to switch it to a live card instead. You may also not really want to scan "forever", but may want to try scanning for a fairly short period of time, then turning it off for a short period of time, and repeating this. Or you may want to turn it off for a period of time once a new packet is received. Your exact needs may dictate this, but given the characteristics of how often advertisement packets are sent out, you may not need to be constantly listening to get all of the packets.
As a current Glass developer myself, I've found that there isn't really any good way around this.
We're all facing this problem. There isn't much room, every is tightly packed, and what Glass is having to do is complicated. It will heat up if you are constantly scanning. Especially when you are taking videos - Glass will become very hot.
I found that lowering the screen brightness helps a bit, at least with the battery life, if nothing else.
This is how you set the screen brightness to its minimum, in case you do want to try it and see if it helps:
WindowManager.LayoutParams lp = getWindow().getAttributes();
lp.screenBrightness = 0f;
getWindow().setAttributes(lp);
I'm currently investigating workarounds for this heat problem as well. Glass overheats quickly when capturing previews and doing heavy calculations or image processing on it.
This paper is very informative:
http://arxiv.org/pdf/1404.1320v1.pdf
Title: "Draining our Glass: An Energy and Heat
Characterization of Google Glass"
I'm trying to track down a power consumption issue. I know that something out there is using sensors while the device is quietly lying on its back with the screen blank, but I can't tell what.
Is there a way to find out what process is using sensors? (Gravity, in this case.)
I'm working with android sensor data. My application use
SensorManager.getRotationMatrixFromVector(
mRotationMatrix , event.values);
and it has been working well until this morning, when the rotation matrix started to send a lot of noise data (Change N to W in a second).
It's not a problem with my code, because on friday was working and no changes have been done. I have used a compass app from the market, and the compass is giving random data.
I have tested my app on another tablet, and it is working well.
Does someone know why is this happening? A problem with the sensor? Does it need a calibration?
I've worked quite a lot with these electronic compasses on mobile phones and its quite possible that there is nothing wrong with your code or sensor.
Instead it could very well be a problem with your environment. There are magnetic fields interfering with the earth's magnetic fields all the time. From electrical equipment interference to the metal structure holding up a building. At the end of the day a compass is just a magnet. If you stand beside a large lump of metal the compass will be attracted to it and point to it rather than the magnetic north pole.
Try this:
Install GPS status
then turn off all filtering (settings... gps & sensors...sensor filtering... no filtering).
Do the calibration (figure of 8 wavy stuff) and then move the phone around your desk.. near monitors, cables, etc. You'll see it go crazy. The information is completely unreliable. I found in the past that moving the phone a few inches to the right completely changed its reading. The same happens with a real compass. Strictly speaking there is no "problem". The device's compass is assigning itself with the strongest magnetic field. Even the magnetic content of nearby rocks can interfere with the compass.
As a further test I've just placed a real (orienteering) compass over my phone which has a compass app installed. The real compass is now pointing everywhere but magnetic North. The two devices are interfering with each other.
So my advice is.. go somewhere in the open, like a park or field, away from any potential interference and power lines, (if you have one bring a real compass to check that the GPS status app is pointing the right way), and see if your compass works as you'd expect.
Extra: The answer from #resus is also important when calibrating. Rotate the phone a few times in each axis. Looks silly but it does calibrate it properly.
Extra 2: Would it be possible/practical to use the compass bearing of your GPS? It would require that the device be moving (walking speed should be fine) but you would not need to worry about any interference. It should give an accurate reading provided your GPS signal is good.
Extra 3: Another thought just occurred to me.. You could try apply a low pass filter to the sensor. This means that the sudden changes in the sensor reading are filtered out .. have a look at this answer. And if that doesn't do a good job there are lots of algorithms on the web for you to choose from.
If you definitely haven't changed anything in your code, and it still works fine on other devices, it would suggest a problem with that particular device.
While your app is running (i.e. the compass is in use), you should be able to wave it in a figure of 8 in order to automatically recalibrate the compass. You should also make sure you aren't standing next to any large lumps of metal etc. that might interfere with readings.
You can override the onAccuracyChanged() method of SensorEventListener to flash up a message to the user when the compass requires recalibration (probably when accuracy drops to SENSOR_STATUS_ACCURACY_LOW).
In my experience of playing with the compass on android phones, they can be pretty unreliable...
If your application work on another tablet and other compass application do not work on your device, this is probably due to a bad calibration.
As said in the post above, to make the calibration, wave your device in a figure of 8. I just want to add that you should do it for EACH axis. This should fix your problem.
If it is not a calibration error, as some people have already answered, it is possible that the compass had gone through a magnetic field and now it is desmagnetized, so it is not working properly.
Where do you usually keep the tablet? Could it be that it was near big servers or magnets?
You should check the compass just in case, talk to to android's tech support.
Hope it helps.
I think the question was if calibration could be done without sending any data to compass. Because not everybody says that the compass is calibrated as shown in this video: https://support.google.com/maps/answer/6145351?hl=en and obviously you can not do anything else than advise the user to calibrate before using the program or when you get too much changes.
For example going left and right 90 degrees in about 25 ms.
Anyway I think it's good to give some seconds to the app before start taking data, because it gives some unstable values (too high and low in short time without movement) at the app loading moment.
Just let the handler onSensorChanged() coded with a conditional, and start a thread on the onCreate() handler, which will set a boolean to true, after some seconds.
Then you start to capture data on the onSensorChanged() handler.
Also this thread can help to detect the sensor accuracy, and then you can popup: In Android can I programmatically detect that the compass is not yet calibrated?
I know because I am building a robot using the compass of the smartphone, and I'm having this experience. So, if you are making a robot, make sure to give an spaced place between electronics and hardware to the smartphone, but remember that it's on any compass: electromagnetic fields can be altered by metals so heavily.
Nowadays I have the luck of developing a robot with an HMC-5983 and an MPU-6050, which can be calibrated by using its libraries with Arduino.
That code is compatible/portable to other uController but for not also so easy for smartphones, I guess that the offsets needed for calibrating the compass, the gyro and the accelerometer are inside some internals of Android, not available in the SDK.
I answered before thinking that maybe calibration was only for some devices, but realized that must be as I said before.
So, if playing with robots its possible, I mean it's also easy, but when using an smartphone maybe some custom firmware as CyanogenMod would bring the possibility of investigating the way of setting that offsets, but more important to run some program ported from sketch (following its concept only) to get them first ...
So, good luck ! What is also true, is that in both devices (smartphone and my robot) it's need to move them for them to get working well, as I showed you in the video of latest answer, also helpful on robots.
Good luck and a lot of fun with those things, are very powerful.