[Galaxy S II General] gingingingin:
1. Abstract

2. Approach

3. Baseline configuration and results

4. References

5. Disclaimer

1. Abstract

Initially I was quite dissapointed with the battery life of the Samsung Galaxy S II i9100 with Android 2.3.4 out of the box. Coming from the Symbian world Nokia E71 I have been used to 6-7 days without recharging, while on SGS2 I got barely 1.5 days of normal usage. I started to optimize, and felt that the hardware is very capable for power saving, but the software is not optimized. After turning off all synchronization, going thru every program settings to switch to manual sync, switching to 2G network (EDGE in my area), turning off WiFi/Data/GPS/Background data I've got a busy day full of meetings at work (didn't touch the phone apart from 2 incoming calls and a few notes) and only 10% decrease of battery for 24h (100%->90%) which is amazing by itself. But I wanted to optimize more.

I have heard that other things like Custom ROM, freezing of system applications, task killers, Under Volting (UV), Under Clocking (UV) would help me too, but I was about to discover which one really helps in real use.

One lazy Sunday like today while being a bit sick allowed me to conclude an experiment of how far did I get in optimizing the power usage for a "baseline configuration" - WiFi/Data/GPS/Background data off, 2G network, all possible sync to manual - and the results are astonishing.

2. Approach

The approach to optimize the battery life is only one - PUT IT TO SLEEP AND DON'T LET IT AWAKE.

Having read a ton of articles on xda-developers.com and other places I have concluded that the strategy for optimizing includes these major steps:

2.1. Get a clean baseline Custom ROM where much of the "bloatware" is removed, so you have less to optimize - optional step but it helps to do it

This probably helps although not necessary. I'm not sure if the stock ROM will allow you to put custom kernels which will be needed in the next steps to optimize further.

But in any case you need to be at least "rooted" to apply some of the advice - either via a rooted kernel like CF-Root [8], or via an exploit like the DooMLoRD'a zergRush exploit [7].

2.2. Optimize the screen-on time

This is up to how frequently you use the phone :)

What you can optimize is to set a default "conservative" CPU Governor profile from 200MHZ to 1200MHz for regular usage - nothing really special, it's only slower on jumping to high frequencies.

If you have a kernel like RedPill Kernel [9] you can add an additional In-Call profile with "conservative" CPU Governor from 100MHZ to 800MHz - while you talk and phone to the ear it idles at 100MHz, but if you start a let's say Notes taking application, or go to turn on Bluetooth it will be snappy enough. Same holds true for listening to music or listening to books - but it's up to your imagination how to set a 100MHz profile in this case (maybe via Tasker). Have in mind that the 100MHz setting may be unstable on some phones because it's not standard, but mine is absolutely fine with that setting.

For setting the CPU profiles software like Voltage Control [5] (paid version for many profiles) is used.

CPU Governor "conservative" is crucial so you don't instantly jump to the highest frequency as it happens with the default "ondemand" governor (or its clones).

You can choose an I/O Scheduler appropriate for your CPU Governor based on the MagicConfig article in my references [14].

People also say that the following helps and I use it: turn off button LED lights, darker wallpapers, auto-rotation disabled, auto brightness on (I have to see the screen after all).

If you use kernel like RedPill Kernel [9] the button LED lights are undervolted by default, so you can leave them "on for 1.5s" for example.

If you have a Custom ROM like CheckROM Revolution HD V6 [10] with JKay Deluxe Settings you can set a Dark or Darker auto brightness profile - also usable to some extent.

One article in my references [12] also gives the power drain in milliwatts (mW) for each hardware device - go read it and you will understand how much the Amoled Display (Average - 370mW), LED lamp next to camera (1.3W), Camera (700mW), Bluetooth and GPS (110 to 180mW) etc. hardware actually consumes.

2.3. Optimize the screen-off time

2.3.1. Analyze Wakelocks

Wakelocks indicate when some application prevents the phone from going to sleep for some time. It does not necessarily mean that it does something significant at that time, and may be only a bad application design. Some applications really like to hold wakelocks periodically during the day for no reason, even if set to Manual sync etc. Examples of such applications are Facebook, 3G Watchdog... You milleage may vary but you can be sure that this hurts your battery life a lot. Any such application can be frozen with Titanium Backup or uninstalled if it's not a system application. Both count and total duration of the wakelocks are important.

BetterBatteryStats [1] has a screen to debug Partial Wakelocks and Kernel Wakelocks. You can also obtain the raw information via the console command "cat /proc/wakelocks".

2.3.2. Analyze Alarms

Alarms are a way to start jobs in the system at a predefined time. Many applications set alarms to get awaken and check/poll something before sleeping again. You should note that firing an Alarm is not necessarily connected to having a Wakelock - you can see many alarms firing but very few wakelocks. The problem is that too many applications set too many alarms for no reason. These activities also hurt your battery life a lot. Examples of such applications are Google Maps (at least for me)... As long as I have another GPS application with offline maps, I've simply frozen Maps with Titanium Backup. Another example was let's say Social Hub, but as long it was firing once per 24h, I didn't bother to touch it.

BetterBatteryStats [1] has a screen to debug Alarms which requires Root access. You can also obtain the raw information via the console command "dumpsys alarm".

2.3.3. Analyze Network Connections

If you get lost in the Wakelocks and Alarms, you can help yourself by checking what connections are kept alive while Internet is connected. OS Monitor [3] has a Connections screen which is equivalent to "netstat". This is also a good indicator what may be drawing unnecessary battery and respectively freeze/uninstall. In my case I can point that I've discovered that K-9 Mail had a bug with IMAP accounts - if I connect to an IMAP account set to manual/poll sync once, it keeps a connection open forever, until you restart or kill the process, but for POP3 account there is no problem... Being aware of such things really help with the battery life.

2.4. Optimize deep idle and sleep time

This is the most important goal in this article - how to get into deep idle/sleep and stay there, because this is the only real way to save energy on such a powerful device :)

CPU Spy [2] can show you how much time you spend in deep idle/sleep - with my baseline testing I've managed to get 99% deep idle/sleep which is amazing - only if the manufacturers gave us the phones in this state and we can build on that...! But it's the other way round.

Unfortunately the sleep mode on the stock kernel and the CF-Root kernel is not too deep. Entropy512 in my references [15] describes the following modes of idle/sleep:

IDLE - clock is gated but power remains (does not eliminate any static power consumption)

AFTR - clock is gated, CPU core power removed, cache power remains - this eliminates a great deal of static power consumption - cannot be entered if second core is active

LPA - AFTR + removal of cache power - cannot be entered if second core is active

IDLE is entered if the CPU is expected to be free for 4 msec (40 msec stock)

AFTR is entered if the CPU is expected to be free for 10 msec (disabled stock)

LPA is entered if the CPU is expected to be free for 40 msec (40 msec stock)

This compares to suspend, aka deep sleep, which takes around 150 msec to enter and 650 msec to resume, and the CPU must be at 800 MHz (or at least have enough voltage to support 800 MHz operation) during this time. Entering suspend/resume is very costly in terms of power due to heavy interrupt load.

Unfortunately my knowledge ends here, but flashing a kernel like RedPill [9] with Power Saving features and patches enabled improved the deepness of the idle/sleep very significantly, let's say 2 fold compared to the stock kernel. Sleep is entered faster and with more savings.

2.5. Optimize the modem/baseband

If all the points above are done, you can consider some savings from trying to flash newer modem/baseband compatible with your Custom ROM for better power savings during Calls and Data transmission. I did not get deep into this yet, but it's rather a big Voodoo, because the contents of the various modems are not public and you can only read feedback like "works very good for me" and "totally awful", which is not very scientific. Initially you can try staying with your original modem or the one provided by the Custom ROM, and optimize the previous points.

2.6. Optimize other stuff

2.6.1. Under Volting - will probably help, but for every frequency you need to choose voltages that are not too low to keep the phone stable. You can try the UV profile from the MagicConfig article from my references [14].

2.6.2. Under Clocking - I consider trying to use 100MHz useful for some scenarios, but only as an additional profile. After all the phone is very powerful and snappy to cripple it with 100MHz-1000MHz profile as default.

2.6.3. Automatic Task Killers - absolutely worthless peaces of software [16]. Android OS is good at power saving. It is very power saving conscious actually, of course combined with capable to sleep hardware. The only reason to kill a process is if it locked on holding some resource/connection forever, and OS Monitor [3] can kill it.

2.6.4. Battery charging - charge the battery as frequently as you want, but be sure to not keep it constantly on high charge (90-100%) [18], as long as this is not a good state for storage. Making bigger cycles helps to maintain better battery life. Some sources say cycling from 0% to 100% is not optimal [17], but from my experience through the years this way also works good for battery longevity, and maintaining small loss of capacity. I can give an example of losing up to 10% of battery capacity per year compared to design capacity with this method. You can view such statistics in Power Management tools in Lenovo ThinkPads etc.

Note that the battery indicator has some tweaks around 100% so consider the following:

- When charging for me it hops from 98% straight to 100%. If you disconnect now, it drops to 98% again, and this is what other people complain from too. Just wait some more time and it will charge to real 100% to have more battery life.

- The indicator stays at 100% longer than at any other value. So when testing, always test from the same baseline, e.g. always charge to 100% before comparing results.

3. Baseline configuration and results

CheckROM Revolution HD V6 PDA XWLA4 (Android 2.3.6) + modem XXKI4 (was XWKL1 but changed for no reason) + kernel RedPill 1.3.

WiFi/Data/GPS/Background data/Auto-rotation/Button LED lights - OFF

Any type of Sync or Polling - OFF/MANUAL, using local Contacts and local Calendar

Widgets - AccuWeather.com on MANUAL and Today view from Calendar.

Network: 2G (EDGE in my area)

Background and lock screen: Dark wallpapers

CPU default profile: conservative 200MHz-1200MHz

CPU in-call profile: conservative 100MHz-800Mhz

Because I don't want to wait a full day for the statistics, I'll post now for 8 and 12 hours, and tomorrow add for 24 hours.

(See the attached images, because I'm not sure how to embed them in the text)

4. References

[1] BetterBatteryStats XDA Edition - http://xdaforums.com/showthread.php?t=1179809

[2] CPU Spy - https://market.android.com/details?id=com.bvalosek.cpuspy

[3] OS Monitor - https://market.android.com/details?id=com.eolwral.osmonitor

[4] Titanium Backup (paid version) - http://matrixrewriter.com/android/

[5] Voltage Control - https://market.android.com/details?id=com.darekxan.voltagecontrol

[6] Android Terminal Emulator by Jack Palevich - https://market.android.com/details?id=jackpal.androidterm

[7] DooMLoRD's Easy Rooting Toolkit [v4.0](zergRush Exploit) - http://xdaforums.com/showthread.php?t=1321582

[8] CF-Root Kernel - http://xdaforums.com/showthread.php?t=788108

[9] RedPillKernel_Rev1.3 - http://xdaforums.com/showthread.php?t=1288850

[10] CheckROM Revolution HD V6 - http://xdaforums.com/showthread.php?t=1312240, http://checkrom.com/

[11] Premium Dark Wallpapers - http://xdaforums.com/showthread.php?t=1474798

[12] Kernel Governors, Modules, I/O Schedulers, CPU Tweaks - http://xdaforums.com/showthread.php?t=1369817

[13] Getting the Most out of the Battery on your Android device - http://softbanksucks.blogspot.com/2011/10/getting-most-out-of-your-battery-on.html

[14] MagicConfig for UV and CPU Governor + I/O Scheduler combinations - http://xdaforums.com/showthread.php?t=1466017

[15] Entropy512 explained CPU idle states - http://xdaforums.com/showpost.php?p=23252902&postcount=17

[16] Android Task Killers Explained - http://lifehacker.com/5650894/andro...ed-what-they-do-and-why-you-shouldnt-use-them

[17] Li-Ion Battery Charge Cycles, Voltages and Storage analysis - http://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries

[18] IBM/Lenovo recommendations on Li-Ion battery treatment - http://xdaforums.com/showpost.php?p=23258191&postcount=19

5. Disclaimer

Paid apps are mentioned here for clarity. You can of course find an alternative if such exists. Free (no ads) versions of software were listed where possible.

Needless to say that all advice here must be applied only under your own responsibility.