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
Related
I know that everyone keeps saying it's low but is there a way of getting real numbers instead of just saying "low" ? Like Fused location provider, it officially says it consumes 7.25% per hour if it's updated every 5 seconds in high accuracy mode. Why can't I seem to find any official given percentage about activity recogniton?
I need a documented result because I'm writing a scientific article and I can't simply use the term "low" energy consumption. If such estimation isn't provided in the official Google I/O does that mean that I'll have to just test it myself ?
Yes. You have to test it yourself. For activity recognition there's a lot of things in play, for example: hardware available to the API, not all device has all the sensors supported in Activity Recognition.
I've done several experiments in which I bypassed the battery and measured the power being drawn on a few devices, and I can tell you that even the same sensor draws a different amount of power on different devices. To complicate matters even more, some devices have a hardware FIFO, which saves power on these devices compared to those that don't, and it looks like ActivityRecognition API may be taking advantage of it on these devices.
I would recommend you choose a few different devices and just run some power experiments on them. Make sure you keep track of the API level used, since the hardware FIFO was only exposed in API 21+. Also, keep in mind that ActivityRecognition goes into a lower power state if it is still for too long, so find a way to keep it moving.
I'm working on an app that uses a MediaPlayer object to play H.264 MP4 videos from a WallpaperService as it is a live wallpaper app. Battery drain occurs while the device (Nexus 5, Android 6.0.1) is idle and sleeping if I pause/stop the MediaPlayer with mediaPlayer.pause() or mediaPlayer.stop(). The drain is about 3-7%/hour as tested multiple times overnight. As soon as I release the media player with mediaPlayer.release(), the battery drain goes back to a more normal 1%/hour. I pause/stop the mediaPlayer when onVisibilityChanged calls false. The phone is reporting to be going to sleep in both the stock Android battery chart and Better Battery Stats.
How can this battery drain be explained if the CPU is going into a sleep state successfully?
EDIT: Something new I've discovered is that when calling mediaPlayer.setSurface(null) right before mediaPlayer.pause(), the idle battery use comes back to normal. I can then do mediaPlayer.setSurface(surface) to set it back before mediaPlayer.start(). The problem is there's some black artifacting for a couple of seconds after restarting.
I can't give you a precise answer but can give you what to look for. I suspect what is going on is that pause() is checking for events frequently enough to keep the processor from entering the deeper sleep/C-states. In contrast, stop() doesn't need to check for events and so allows the processor to enter a deep sleep state. I wrote an article on sleep states some years back.
I suspect that the writers of the function decided to check more frequently than is necessary. This is a very common mistake due to the developers thinking that shorter sleeps / more frequent checking result in better response (which it almost never does). You can check this by using a processor power monitor that actually checks the hardware sleep states. Unfortunately, most don't and only check for processor independent "equivalents".
So let's get back to your question: What can you do about it. I can give you some advice but none of it is very satisfying:
Check for an API or data structure that allows you to set the
checking interval for pause(). By the way, I don't know of any.
Write your own. Of course, this complicates writing platform independent apps
Use an alternative media player that has done this correctly
Hammer on google until it's fixed
Like I said, none of this is very satisfying. By the way, searching the net, I found evidence that this has happened more than once with new Android releases.
Good luck and let us know what happens.
The Google Fit app, when installed, measures the duration you are walking or running, and also the number of steps all the time. However, strangely, using it does not seem to drain the battery. Other apps like Moves which seems to record number of steps pretty accurately declares that it uses a lot of power because of it constantly monitoring the GPS and the accelerometer.
I imagine several possibilities:
Wakes up the phone every minute or so, then analyses the sensors for a few seconds and then sleeps again. However it seems that the records are pretty accurate to the minute, so the waking up must be frequent.
Actually turns on the accelerometer all the time, and analyzes it only after the accelerometer measurement data buffer is full. However I think the accelerometer has a small buffer to store the latest measurements.
Use GPS to estimate the number of steps instead of actually counting it. However this should not be the case, since it works even indoors.
The app still feels magical. Counting steps the whole time without perceptible battery drain.
Thanks for asking this question!
Battery is one of our top most concerns and we work hard to optimize Google Fit's battery usage and provide a magical experience.
Google Fit uses a mix of sensors(Accelerometer, Step counter, Significant Motion counter), Machine Learning and heuristics to get the data right. Our algorithm is pretty similar to your 1st option plus a little bit of magic.
We periodically poll accelerometer and use Machine Learning and heuristics to correctly identify the activity and duration.
For devices with hardware step counters, we use these step counters to monitor step counts. For older devices, we use the activity detected to predict the right number of steps.
Our algorithms merge these activities, steps and sometimes location to correlate and further increase accuracy.
We do not poll GPS to estimate steps or detect activities.
-- Engineer on Google Fit Team.
On some very recent phones like the Nexus 5 (released in late 2013 with Android 4.4 KitKat), there is a dedicated low-power CPU core that can serve as a pedometer. Since this core consumes very little power and can compute steps by itself without the need for the entire CPU or the GPS, overall battery use is reduced greatly. On the recent iPhones, there is a similar microcontroller called the M7 coprocessor in the iPhone 5s and the M8 in the iPhone 6.
More information here:
https://developer.android.com/about/versions/kitkat.html
http://nexus5.wonderhowto.com/how-to/your-nexus-5-has-real-pedometer-built-in-heres-you-use-0151267/
http://www.androidbeat.com/2014/01/pedometer-nexus5-hardware-count-steps-walked/
having a 3 year old HTC OneX I can say that THERE IS NO DEDICATED HARDWARE, Google Fit just uses standard sensors in a very clever way. I come from Runtastic Pedometer: there is a clear battery consume when in use, it would be impossible to keep it on all the time as it needs the full accelerometer power. On the other side, if you stand still and shake the phone Runtastic will count the shakes, while Google Fit apparently does nothing... Still it works perfectly when you actually walk or run. Magic.
Google fit try to learn use pedo step pattern and try to create its own personal walking patterns and its clusters. This eliminates the need of having huge mathematics calculations on receiving sensor data every time. This makes Google fit more power efficient compared other software pedo apps. Having said that, there is compromise on accuracy factors here. Between power-accuracy trade off, google seems to be more aligned towards power factor here.
At this moment the most power efficient detection happens Samsung flagship & its other high end models. Thanks to Samsung's dedicated hardware chip! No matter how power efficient your software pedo algorithm be but its hard to beat dedicated hardware unit advantage. I also heard about Google's bringing dedicated hardware unit for Ped upcoming nexus devices.
It would seem like the solution would be device dependent, with devices where a co-motion processor or "wimpier" core is available for low power operations, that it would default to this once the buffer is full or similar condition. With devices where a low-power core is not available, it seems like waking the device could trigger a JIT operation that would/should finish by the time the app is called.
While the Nexus 5 does have a dedicated "low-power" pedometer built in. It isn't as "low power" as you might think.
My Nexus 5 battery life was decreased by about 25% when I had Google Fit Activity Detection switched on.
Also, the pedometer doesn't show up in the battery usage stats. Presumably, because it is a hardware thing.
I don't know for the other phones out there, but Google Fit was really draining my battery life on my Nexus 5. Disabling it definitely improved my battery life.
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"
Hey, I finished my code and everything works as it should but I'm wondering since smartphones have limited battery, CPU .. How can I check if my application will run good on older phones? and how can I check if my app consumes the phones battery?
Thanks
The only way to really know it to test the app in the phones.
That said, you can profile it and make educated guesses based on how CPU-intensive is your app, for how long is it running, if you have services using cpu continuously, etc.
There are a few things to consider:
The main battery drain is the screen. If you keep any kind of screen lock (even dim), it will destroy the battery.
Any other lock (wifi, etc.), will induce battery drain. Do you use them? Do you need them? Do you release them as soon as they're not needed?
Do you have hardware listeners (e.g., location, accelerometer), unregister them as soon as they're not needed
Take a look at this video: http://www.google.com/events/io/2009/sessions/CodingLifeBatteryLife.html
Also take a look on
http://developer.android.com/guide/developing/debugging/debugging-tracing.html