[Guide] Android Battery Saving Tips – Part 3 / 3

This is the 3rd in the series of Android Battery Saving Tips. If you haven’t already, refer to the first and second parts of this series for beginner and intermediate tips, respectively. In this article, we will be visiting some more advanced techniques used to save a bit of battery power. Note that, just as with every other tip in this series of articles, it is purely optional, your phone will work fine without them for a long time. For those that want to fiddle a bit and are curious, read on.

Preferred Network Type: Most of the Android phones released locally (especially unlocked phones) will be set to scan periodically for a mobile network to connect to and join that one. This is designed for the phone to find the best signal at all times, but this is a compromise on battery life. You can manually set the network type yourself to experiment if this yields any battery life improvement, particularly if you are often in metro areas. To access the service menu, start the ‘Phone’ application (not any 3rd-party phone dialers) and type *#*#INFO#*#* (which equates to *#*#4636#*#*). Select ‘Phone Information’ and select the drop down menu that appears. According to a chap over at XDA, here are the purposes of the different settings:

“GSM only” <—- If you don’t get 3g with this it is the same as 2g setting then use GSM auto (PRL) if you want faster than 2g (as some people are getting 3g on GSM only – I will investigate. (if you don’t use internet or don’t need fast internet)

“GSM auto (PRL)” (Recommended)
1:40am to 2:00pm (12hrs 20 mins) – lost 40% battery with moderate use a bit of surfing at HSDPA speeds, a few calls and messing with a few apps. Other people have had even better results than me though, so I might change my rom and try again.

“WCDMA Only”
2:06pm to 11:37pm – (9hrs 31mins) lost 46% battery again moderate use and a reboot
This one might be useful if you live in a place that has low GSM signal as it does give HSDPA – but this is only a suggestion as I cannot test it in Iceland.

“WCDMA preferred”
6:02am to 2:51pm – (8hr 49mins) lost 41% battery this time with less use that the WCDMA use and no reboots.

Note that WCDMA should not be confused with CDMA, which is different. My personal experience with this is that GSM Auto (PRL) [Here is the definition of PRL, in case you were wondering] yielded slightly better results. If I set it to GSM Only, it would more often result in ‘Roaming’ rather than 3G connection. The phone from factory was set to WCDMA Preferred. The best way is to trial and error yourself, see which ones pick up a good connection and monitor battery use from there. A reboot is not required, just select the option you want and wait a few seconds for it to re-associate. Best results are usually had by manually selecting your carrier under ‘Network Operators’ rather than ‘Select Automatically’, so as to prevent constant scanning of new providers.

SetCPU (root required): As you know, the current crop of Android devices are powered by the Qualcomm QSD8250 ‘Snapdragon’ 1ghz processor. You may also realise that the CPU does not always run at 1ghz, only throttling up when required, in order to save power. What speeds it throttles between, and how fast is responds to demands on it, can be set via SetCPU. How it works is this, after starting SetCPU, you will notice two main sliders, min and max. Self-explanatory, 998mhz (1ghz) is the normal maximum, and 245mhz is the normal minimum. The auto-refresh will show the current speed in the top left. Drag the notification bar down a few times and you will see the CPU speed fluctuate rapidly in response to this. Also important to remember is that voltage to the CPU (normally pegged at 1000mv @ 1ghz) closely correlates to the CPU speed itself. A lower CPU speed at any time will require a lower amount of power, hence lowering battery use. For most people, limiting the CPU to a lower cap permanently will result in substantially reduced power draw, however this is unacceptable for most people who still want a ‘snappy and responsive’ experience. Here are my recommended settings (some of which are located in the ‘Profiles’ menu), which can be applied to any Snapdragon based phone (N1, Desire, X10, etc):

Main – Min 245mhz / Max 998mhz (as per standard, nothing surprising here. Raising the lower limit has little to no purpose, as it just affects the idling mhz of the phone, and will increase power draw as a result. You can try lower than 245mhz but may encounter strange behaviour).

Charging – Min 245mhz / Max 998mhz (this is the same as Main, but is required because if the phone enters low power mode [see the following profiles], you want to phone to ramp back to normal when plugged to charger).

Sleep/Standby – Min 245mhz / Max 384mhz (probably the most important setting, when the screen is off or you press the Power button to enter standby, these settings take effect. The max is capped at 384mhz because it’s extremely rare for any process running in sleep mode to require more than this amount of processing power. You can try capping it at 245mhz, but may encounter strange behaviour [such as a slight lag when you receive a phone call]).

Power < 40% – Min 245mhz / Max 528mhz (Self-explanatory. Your phone is starting to get a bit low on power, throttle down the CPU to 528mhz, low enough so that there is a noticeable dampener on power draw, but also not too low that it becomes too sluggish).

Power < 20% – Min 245mhz / Max 384mhz (OK this is getting urgent, your phone is nearly out of juice. Your CPU throttles down to something barely usable, but should be enough to stretch out that last few joules of energy for a while longer).

Failsafe Profile > 50deg – Min 245mhz / Max 384mhz (In the event your phone is overheating, like say you left it in the scorching sun in a closed bag, very rare, then this will throttle your CPU down to cool it down. More of an insurance policy than a battery saving mechanism).
You will also notice in the advanced menu there are two options of note. The first being ‘Sampling Rate’. This is the rate at which the phone checks CPU usage and decides based on the ‘Up Threshold’ if it should ramp the CPU up to the next level. Measured in milliseconds. A lower rate will be quicker to respond, but there is a slight overhead. Generally a value of somewhere between 30000 to 80000 is normal. You can experiment with this till you find a setting which you don’t feel is sluggish.  The ‘Up Threshold’ is the CPU usage value at which the phone will activate the next highest CPU speed rating. Normally set at around 80-85%, if CPU usage exceeds this, it will ramp up the CPU. You may also notice Ignore Nice Load, which ignores some pre-specified services from factoring into CPU calculations, and also PowerSave Bias, which artificially limits maximum CPU speed. Both of these should be left at 0. On some kernels, you may also notice there is a ‘conservative’ processor scheduler, in addition to the normal ‘ondemand’. This has a more lenient ramp rate, usually around 200000 ms for the Sampling Rate, which generally results in slower ramping, possibly perceivably slower ‘snappiness’ of application, but a noticeable improvement in battery life, without sacrificing the cap speed.

Undervolted Kernel (root required): The Android OS is kept on the ROM, which can be loaded with different systems (referred to as loading a new ROM, many of which have optimisations to it over the stock one). However, you can also load a different kernel in addition to the ROM, which in turn may also have further tweaks and optimisations to save more battery. Note that some kernels are not compatible with some ROMs, and that most 3rd-party kernels generally use newer versions (.33-.34) where the official Android releases may use older version (.29-.32) for compatibility or stability purposes. The benefits of different kernels vary, but generally they fall into three categories:
Scheduler BFS Scheduler or CFS Scheduler, as seen in Linux – The CPU scheduler used in the ROM dictates how resources are allocated and prioritised. The BFS scheduler generally places higher priority on the foreground application, resulting in more responsiveness for the user, or higher benchmark scores, but may adversely affect background applications (of which there are many in Android). The CFS is more commonly used and as the name suggests is ‘fairer’ in it’s allocation of CPU, which will result in background apps running more happily. Some people have have had good experience with BFS, although most ROM creators have since moved towards CFS as they encountered problems with BFS (stating that it’s not suited the Android’s architecture).

Voltage – The Snapdragon CPU runs at 1v (1000mv) from factory, but general experimentation has determined it can be undervolted in order to save power. Some kernels will allow you to load on different variants of voltages, the most common being 800mv and 925mv. There are mixed reports about the 800mv kernels, with some people reporting instability, and some people reporting higher power draw (which is counter-logical). I’ve tried both and have ended up settling on a 925mv CFS kernel.

Overclocking – Not strictly related to saving battery (quite the opposite), but some kernels also allow for the CPU to be clocked above the standard maximum. Snapdragon CPU’s are capped at 998mhz from factory, but can generally be safety clocked up to 1.113mhz or higher on the standard voltage or below. Some owners have even reported that 1.267mhz is achievable with some tweaks. Note that this will of course, drain your battery faster.

Which kernel? If you’re using a Nexus One, you have a choice of the latest kernels from XDA regulars, such as pershoot (OC+UV), WildMonk (OC+UV) and IntersectRaven (UV Only) (found on XDA-Developers). You can trial and error different kernels (assuming they’re compatible with the ROM you’re using) to find one that you have the best experience with. I started off on the IR kernels, found them to be very stable, had some stability issues and lags with WildMonk’s kernels, and eventually ended up with Pershoots OC+UV kernel (with extra RAM hack). Definitely the smoothest, quickest and most stable of them all in my opinion.

Tasker: If you’ve heard of programs like Locale, Settings Profiles or Juice Defender, they offer battery saving capability in that, but you will notice something in common. They will execute an action (such as toggling various phone functions), based on pre-defined criteria (like a time period, location, battery level, etc). So for example, at a certain time period (ie. when you go to sleep), you can set it to reduce power consumption functions like syncing your e-mail. Common sense right? Or it can reduce the frequency of data sync to a pre-set period, like 15 minutes, this is the premise of Juice Defender. This can make a substantial difference in how much power your phone draws as it’s not always maintaining an active data connection. But what if you want very fine control over these parameters, in a software that’s free? Enter Tasker, a project of a solitary man that does what all of the above does, but does it better. Download link here. However, note that Tasker can be intimidating for beginners, so I will write a simple guide in another article coming up soon. Also note that the author is planning to move this to a paid app soon.

How does it all tie together? OK so now that you’ve read this far, and you may or may not have utilised some of the information presented to you in this trio of articles, hopefully you not only have a better understanding of how you can take steps yourself to improve the battery life of your device. Generally some common sense in usage and quick toggling of functions should see your battery life extended considerably. If all else fails, or you use your phone a ridiculous amount, then you should invest in buying some car or wall chargers around the place / in the car / at work. These are generally a few dollars from eBay, or you can look at an extended battery from eBay as well. The one I purchased was a 2700mAh model (vs the 1400mAh of the stock battery) for around $18 AUD landed.

If you want to do some further reading, this is a fascinating insight into battery usage of Android devices, by a trio of PhD students, at an event organised by SF Android Users Group. Some great info about the current state of mobile devices, what components on your phone are taking up battery (display and 3G/Wifi radios, CPU ranks a distant 4th or 5th IIRC), and what is being done about it.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s