How to Increase Battery Charge Life by Eliminating Sleep-Mode Rogues
Several Things to Understand
(1) Every time an instruction executes, the battery loses a tiny amount of charge.
(2) A given app executes a number of instructions per second that is often (but not always) dependent on the amount of user interaction with the app. So, using that app for X amount of time will drain your battery by Y amount. Although the app coders and ROM cookers may squeeze a bit more efficiency out of the system through code optimization, battery drain caused by using apps is largely fixed and you can do nothing about it other than not using the app (which, of course, defeats the purpose of having a smart phone).
(3) The above is the bad news. The good news is that most of us (particularly if one is gainfully employed) interact with our phones for a relatively small percentage of our 24-hour day (during which time we have little control over battery drain, as mentioned above). That is very good news, because it means that during most of our 24-hour day we can
(potentially) control battery drain. My phone uses less than 1% per hour on standby precisely because it really is
on standby. This is not rocket science; and I will explain how to do it.
(4) What "He Who Is Sworn to Do No Evil" does not want you to know.
(Or: Google Meets Pocahontas.
). The Android OS and many of the thousands of apps are free, right? Wrong! Nothing in life is free.
The heart and soul of Google and others in this business is data collection and monetization of the collected data
. Doing so takes lots of CPU cycles, including all of yours that these companies can possibly wrangle from you without upsetting you too much. Think of this analogy... The English arrived at Jamestown and traded shiny beads and trinkets for food, land, and other valuable stuff. Google and company trades you a shiny new OS and app toys in exchange for your data, which they have thus far managed to monetize in amounts greater than the GNPs of many countries. I wonder how many of those screaming for Froyo and Gingerbread realize that increasingly intrusive CPU cycle-hungry data collection tools will be imbedded in every succeeding version of the shiny new OS/app toys. I believe that the rate of increase of those cycle-stealing data collection tools over time will be limited only by the rate of hardware performance improvements over that same time, such that the natives do not get too restless due to lag, battery drain, etc.
How to Fix Your Battery Drain Problem
So now, if you have endured my philosophical rant (or have been clever enough to skip to this point), here is how to fix your battery drain:
(1) Purchase the Pro versions of SystemPanel and Titanium Backup. (No, you will not be able to accomplish this with the free versions; don't waste your time.)
(2) Configure SystemPanel ("Settings") to enable Monitoring
, AppCPU Monitors
, AppCPU Time
, System Monitor
, and System Processes
. Under Monitoring Settings
, checkmark to enable "Start at Boot," "High Priority," and "Status Bar Icon." Under Plot Settings
, checkmark "Usage Plots," "CPU Plots," and "App CPU Plots." Said plot settings will cause logarithmic plots to be drawn. This will reveal small values that otherwise might be hidden down at the bottom of the vertical axis.
(3) Now, on the screen that first appears when you start SystemPanel, you will see all apps that are currently loaded in RAM and active as entries with a grey background at the top of a long list of entries, with the heading "Active Applications." At the left of each app entry is a bar graph displaying CPU activity for that app in real time. The next series of entries, labeled "Inactive (Cached) Applications," with aqua backgrounds, consists of apps that are (supposedly) inactive, with stubs cached in RAM. This group merits an occasional glance during the analysis. Although there should be no bar graph activity for these apps, I have sometimes caught the Market app burning significant CPU cycles while presumably cached. The third and final series of rust-colored entries is labeled "Internal System Processes." Some of these bar graphs will show CPU activity. This is a highly suspect area, because it includes data collection processes built into the OS and running in the background.
(4) Although the real-time monitoring tools are interesting and may be useful to "catch" an app or process burning cycles when the app/process should be inactive based upon your current interaction with the device, this tool is limited precisely because you must catch the app/process in the "act."
(5) So, now press the Menu key down at the bottom left of the screen and then "Monitor" to get to the good stuff. There are two tabs at the bottom of the screen, "Live" and "History," with "Live" being the default when you pull up this screen. The good stuff is under "History." The default screen under "History" shows battery charge state, "Device Usage" (not clear what this means; it is not explained in the Help and I have not yet contacted the developer to ask the question), and CPU Activity. CPU Activity is key to our current effort. You can choose the time period for which the CPU activity is displayed by pulling down the arrow at the upper right of the screen. I rarely use any time period other than 2 or 8 hours. 8 hours is, of course, spot-on for monitoring while you are sleeping. 2 hours is better for a higher-resolution view when you have been using an app for period of time and wish to view the CPU utilization over that period of time.
========>> While the phone is not being used, it should spend a significant amount of time in sleep state.
That is indicated by the green CPU activity color disappearing completely during some intervals along the timeline. The overall appearance reminds me of a cityscape, the green bars being the buildings and the sleep periods being empty space between the buildings. If, while your phone is on the table, not being used (with wifi, Bluetooth, and GPS turned off, of course), your history graph shows solid green along the timeline, then, irrespective of the height of the green areas, you will have confirmed that your unacceptable battery discharge rate is being caused by some app/process that is running while you do not want it to be.
However, you will not yet know the identity of the evil app(s)/process(es). Also note that the total CPU utilization (green bar height) should be not much over 1%, if present at all in a particular time slot.
(6) To find which apps/processes are causing the problem, pull down the "Plot" arrow at the upper left of the screen and select "Top Apps." The resulting screen is a list of apps/processes ordered according to highest CPU usage over the period of time selected using the upper-right down arrow dropdown menu (e.g., 2 or 8 hours). While you are sleeping, your smart phone should be too!
Following my sleep period, my phone shows only 2-4 apps with anything above 0.0%. The app with the most usage will show only about 0.2 to about 0.4% And (this is key), the "suspend" process should be toward the top of the list
. Take note of any app/process that is out of line here.
(7) Now, fire up Titanium Pro. It will take Titanium awhile to load its database and display a list of all apps/processes installed on your phone. Press the Menu key and navigate to "Filters." Make sure that all three filters are set to "All." Press back key then press the "Backup/Restore" tab at the top center of the screen. Scroll down the list of apps/processes to find the potential cycle-sucking app/process that you identified in the previous step (6). Do not un-install anything!!!!
Doing so is unnecessary, could damage your system, and may be counter-productive in any case because it may cause changes in your system beyond simply disabling the suspect process/app. The key here is, to the best of your ability, to change only one thing at a time
in order to precisely pinpoint the problem. Short-press that app/process entry to get to an action page for that app/process. Press "Freeze!" You will receive a pop-up bubble confirming that the app/process has been frozen, and the "Freeze!" button will have changed to "Un-freeze!"
(8) Now, let the phone rest for a couple of hours, then look at history again to see any effect on CPU utilization from having frozen the single
(9) Repeat this process with additional suspect apps/processes until the damn phone sleeps like it should as described in (5) above. If a frozen system process or system app causes instability, just un-freeze it.
(10) Not by accident, I suspect, the Android OS treats the closure of an app ambiguously, at least from a user perspective. How do you "close" an app? (Meaning, for purposes of this discussion, instructing an app to keep a stub in RAM if it likes but not to execute any further instructions until explicitly opened again at some point in the future.) A few apps have an "Exit" button. Others go into this state when you back out to the top of the screen tree. Other apps stay "conveniently" ambiguous when you back out to the top of the screen tree and may show CPU activity thereafter. If you simply cannot live without an app that falls into the latter category (by keeping it frozen), then you may have to explicitly kill it after you finish using it. Ones to watch in this regard (in my experience...ymmv) include Market, Astro, Google Maps, Google Earth, Gallery(?), CardioTrainer (a REAL CPU hog), Dolphin Browser & Plugins, DRM Protected Content Storage (x2???), and Media Hub (this one is really scary).
(11) Another possibility, for an app that you rarely need, would be to keep it frozen except while using it. It only takes a few seconds to fire up Titanium and do the freeze/un-freeze. I have not found this to be necessary, though.
(a) I ony used Advanced Task Killer once in awhile and always in manual mode. It is now frozen, replaced by SystemPanel. Just long-press on an app/process to get to a kill option.
(b) Antivirus was causing too much drain, not because it utilizes much CPU at any given moment but because it must necessarily run constantly, as is the nature of an anti-virus application. I was ambiguous about this decision, but decided to do it on the basis of the ongoing contraversy/doubt as to the risk of virus infection on the Android platform.
(c) The JI2 vs. JI6 modem contraversy regarding battery drain is trivial, imho, compared to the results that you will get by following the instructions above. I highly recommend the system that I am using, described below. It is fast, stable, and the supposedly more sensitive/powerful JI6 modem causes practically zero battery drain in the sleep state.
(d) As a bonus, your phone will charge very quickly because the spigot is not open at the bottom, draining while you are charging.
(e) Although this post is mainly about battery utilization during idle periods, a simple step came to mind for decreasing battery drain during periods of use. The display consumes massive amounts of power. It is generally known that the Vibrant's AMOLED display is emissive, meaning that it emits light rather than passing light from behind. As a consequence, areas of black are created simply by turning the LEDs off in those areas, resulting in low power consumption for those areas. Therefore, black themes can result in significant power savings. Note that this is uber simple to do. Just install a black image as wallpaper! Icons, text, etc. seem to be nicely designed with a mixture of light and dark colors such as to be seen against a black background. In "contrast," the stock Vibrant light green theme is a big power waster. Some apps, like stock browser, will frustrate these efforts by drawing white or very light gray over the wallpaper. That results in an enormous waste of power, because all pixels must turn on to create white. And, needless to say, I keep my screen at minimum intensity except for some quick use while in the noonday sun.
Hmm...well, I guess I just wrote the tutorial.
Here below is an example from a sleep period (my human sleep period, I mean) from 10:00a until about 6:00p. Shortly after waking up, I picked up the phone, fired up ShootMe, and took screen shots of the various SystemPanel history screens reflecting CPU usage over that 8-hour period while the phone was idle, screen off, and not plugged in to anything.
The round blue segmented battery state indicator was 93 when I went to sleep and 89 when I woke up. It fell to 86 during the 15 minutes while I was taking screen shots and looking at email. Not sure how to insert these images in-line, so I will just number the explanations, with each explanation pointing to a screenshot thumbnail, from left to right.
(1) This is the SystemPanel opening screen, showing the apps that were loaded while sleeping (and ShootMe, which I had just loaded).
(2) Moving to the monitoring section, second shot is of the real-time page. Note that CPU activity is low and flat until I begin interacating with phone. It is not really flat, as you can see in subsequent pages; but this particular screen is not drawn with logarithmic scaling for whatever reason, even though that option is selected in settings.
(3) Touching the "History" tab at the lower right of screen displays the total CPU usage over the eight hours. Note that the CPU rarely exceeds 1%, with a much lower average, and that there are a significant number of sleep periods where the CPU is suspended.
(4) Pulling the "Plot" drop-down at the upper left and selecting "Top Apps" displays a summary screen of the apps that were active at some time durng the eight hour test period. The list is ordered from most CPU usage, top to bottom. Note that only two processes, "System" and "System Processes" used 0.1% of CPU power during the test period. All others that were active during the test period at all used less than 0.1%! This is astounding but true, and is the reason why the battery indicator showed a drain of only (93-89) = 4% during the eight hour test period. Note that, at that rate, my phone could lie (lost, for example) in standby for over five days!
Now we will look at the actual graphs for each app/process to see at what points in time
CPU power was utilized. Light touch each app/process in turn and scroll down to see the graphical views. The app/process graph is the top graph. Because of the way that we optioned settings, above, we will also see the entire CPU utilization (bottom graph) for comparison. Note that, in the case of "System Processes," a list of processes is hidden behind the "System Processes" button. The "System Processes" list is then treated the same as the main app/process list.
(5) "System" is a single process. Note that it alternately sleeps and wakes up at fairly regular intervals. While awake, "System" is consuming only the tiniest bit of CPU power. (What, maybe 0.01 or something like that? It is too tiny to be measured on this logarithmic scale.)
(6) "Suspend" is the next graph shown below. It is located behind the "System Processes" entry. It appears to use a bit more CPU than "System" as it executes the suspend algorithm. Even so, it puts itself to sleep sometimes.
(7) SystemPanel app usage is shown next. Note that it appears to wake up from a timer, at very regular intervals, to collect the CPU utilization data for each app/process during the previous interval and to store the data away in its database.
(8) The eighth that I will upload is the history for the "Email" app. It too wakes up periodically to do a pop3 inquiry for new mail, in my case.
So, there you have it. This is the way that you need to persuade your Vibrant to operate for decent battery life. As has been pointed out elsewhere, these issues are not about battery utilization during the night, when most people would have their phones charging anyway. I simply used a human sleep period as a convenient 8-hour test period for battery utilization during phone idle.
What this issue is really about is preventing battery drain that occurs during the day while the phone is not being interacted with or otherwise actively used by discovering and freezing the hell out of ill-behaved apps that, for whatever reason, be it sinister or simply poor coding, continue to operate after being told to stop.
Vibrant w/ Large NAND
16 GB Internal SD and Stock 2GB External SD
Bionix 1.9.1 w/ JAC UV/OC (not OC'd) w/Voodoo (Using SkOrPn & Master's Voodoo/Large NAND method)