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"
Related
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.
I have an application that depends on recording all sounds and analyses it and notify me when it records a specific tone.
So this app consuming battery power as it works all time to detect the sound tone wanted.
I need an idea to prevent this problem please.
Thanks in advance.
It appears that you are not allowing the processor to drop into a quiescent low power state. To allow the processor to conserve power, you need to have the processor idle as much as possible. If you are continuously sampling, this isn't going to happen. My answer here can give you some background.
I suggest you do the following:
Find out what is the minimum fidelity you can use and still identify the tones you want. To say this differently, determine the maximum sampling interval. For example, you may find that you can get by with sampling every quarter second and still identify the tone you want. This will allow the processor to drop into an energy conservation state.
Make sure you are using interrupts and not polling, i.e. use something like usleep(). So to check every .25 sec, you'll use something like while( running ){ sampleTone(); usleep(250000); }.
Check your sound sampling device's capabilities. It may have the ability to do something more sophisticated that will further minimize the number of samples/sec you need. For example, it may allow you to send the samples directly to disk or memory without requiring the CPU to wake up.
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
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 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.