The truth about kernels and battery life

When it comes to Android kernels, the number one topic of discussion these days is battery life. But there are many myths about the relationship between kernel and battery life. At one extreme, there are those who make outrageous claims about radical changes to battery life minutes or hours after installing a kernel.  At the other extreme are those who think the kernel makes absolutely no difference at all to battery life.  The truth lies somewhere in the middle.

Before we get to the “truth” of the matter, I want to clarify a few things.

First, the kernel does not “drain” battery.  Many times, a user installs a kernel and then reports back soon after that the kernel has caused massive battery drain (and probably also something to the effect that the kernel is crap and the dev should burn in hell for his efforts).  To prove it, they post screenshots from battery monitoring apps showing “kernel” as the major source of drain.  This is very misleading.  On Android devices, the kernel provides a mechanism for keeping the phone awake, called a wakelock.  Processes running on the device (e.g. apps and services) can ask the kernel for a wakelock, and the kernel will oblige.  So yes, the kernel is technically keeping the phone awake, but only because an app or service has asked it to.  It is these apps and services that are misbehaving and causing drain, not the kernel. Doze mode, introduced in Android Marshmallow, is designed to limit the time that apps and services can wake up the device.

But that is not to say the kernel does not cause any battery drain.  It still uses memory and does work, but the amount it uses is exceedingly small compared to the Android system, apps and services.  There are also special hardware cases, such as the sweep2wake feature on the Nexus 5 and Nexus 5X, which requires that the LCD panel remain powered on in order to work.  This drains more battery than if the device were suspended normally, but still does not cause “massive” drain.  On the Nexus 5, sweep2wake adds roughly 2% per hour drain while the screen is off.  Not insignificant, but far less than the phone normally uses while the screen is on.  Because of this, a strong myth has developed, claiming that sweep2wake and doubletap2wake cause battery drain.  Except for the Nexus 5, 5X and maybe a few other devices, it is just that, a myth.  On the vast majority of devices, the battery drain from sweep2wake is negligible, usually something between zero and 0.5% per hour, which would “cost” no more than 5% battery usage over the course of a workday.  A perfectly acceptable trade-off for the convenience of sweep2wake.

The second thing I want to clarify pertains to measurement.  How do we measure battery life?  I like to look at percent usage per hour.  Many battery monitoring apps can give you this statistic, but they usually don’t separate screen on and screen off, so you have to pay attention and set custom time points if you want to distinguish the stats further and really understand battery usage.  If you do want to measure and compare stats, make sure you do so under similar conditions. And you must do so over a reasonable time period, which means days rather than hours. If you have some routines where you use the same apps every day, this would be a good way to test and compare. The battery monitor in EX Kernel Manager automatically provides the two statistics I will now talk about: idle drain and active drain.

Idle drain is battery drain while the screen is off.  During screen off, the phone spends most of its time in “deep sleep”.  Sometimes, it wakes up to do some background work, like syncing email or checking for updates.  These would be examples of the system, apps or services “asking” the kernel to stay awake while they perform their tasks.  If all is working correctly, when they finish, the device goes back to sleep.  Idle drain should be measured over several hours to get an accurate picture.  A good time to measure it is overnight while you aren’t using your device (if you are not a dev and actually get to sleep).  On most devices, idle drain ranges from about 0.2% per hour to 0.8% per hour on a stock setup with default options (i.e., with no battery saving measures in place) on a normal WiFi connection.  On some devices, kernel optimizations can shave a bit off this number.  But only a tiny bit, generally in the range of 0.1% to 0.3% improvement over stock.  This is not going to make a huge difference to battery life.  As already mentioned, sometimes hardware features like sweep2wake can eat up about the same amount.  So as we can see, a kernel offers relatively little improvement here, but then again, every bit counts. Another factor that influences idle drain is your network connection, particularly cellular connection.  A poor signal will often result in a bit of extra drain.  But this should not cause excessive drain during idle, and will mostly make a difference while you are using the data connection.  I should add that many of the battery saving measures people take also make little difference here.  As long as your idle drain is below 1% to 1.5% per hour, don’t even worry about it.  If it’s more than 1.5% per hour, look at your apps and services.  Occasionally, there will be a big batch of updates that cause a bit of extra drain.  It happens.

Active drain is the amount of battery used while the screen is on.  That is, while you are using your device.  Active drain is obviously much greater than idle drain.  The phone is on, the screen is on, and it is doing work using the CPU, GPU, memory, modem, wifi, disk, etc.  Active drain varies quite a bit from device to device.  A lot of times we hear about “screen-on time”.  Active drain, measured in % per hour can be translated easily into screen-on time.  Active drain of 12.5% per hour is extremely good and will equate to about 8 hours of continuous screen time.  Drain of 25% per hour will get you about 4 hours of continuous screen time.  See how that works?

Screen-on time (hours)  = 100 / Active drain (% per hour)

This does not take into account the small amount of battery use while the screen is off.  Assuming idle drain is about 0.6% per hour, you would lose about 6% in ten hours, or around 14% in a 24 hour period.  You can subtract that from 100 in the equation above.

Now we’re getting into the truth of the matter.  What influences active drain?  Many things.  Network (especially cellular) connection makes a difference.  Poor signal means it has to work harder to transmit and receive data.  The type of apps you are using makes a difference.  Obviously playing a graphics-intensive game will use far more battery than reading some email. Using the camera, especially flash, will cause more drain than texting.  The point is, what you do with your device has, by far, the biggest influence on battery life.  Something like changing your web browser could have a significant impact on battery life, perhaps a greater impact than any kernel or battery saving tweaks floating around on the Internet. Bottom line: Active drain will vary from user to user, even with the same device!

There is, however, one part of the kernel that has a significant influence on active drain, and therefore can have a big impact on screen-on time.  This is the CPU governor.  This is why kernel developers spend a lot of time tweaking governors.  It’s about frequency usage, which you can measure with an app like CPU Times. The CPU governor controls frequency scaling according to system load.  While not busy, the CPU will stay at its lowest frequency, which uses the least energy.  When there is work to do, the CPU governor ramps up the frequency so the work can be completed faster and the user can enjoy a smooth experience.  A good governor is responsive, quickly responding to changes in system load, to prevent lag, but also quickly returning to the lowest frequency to save energy.

There is an idea called “race to idle” which suggests the governor should immediately ramp up to the highest frequency so tasks can be completed as quickly as possible, and consequently, the CPU can more quickly return to a lower power state.  This logic is generally sound, but with modern processors, there may be a negligible time difference for completing a task using the highest frequency available compared to a frequency somewhere in the middle.  In other words, it may be a waste of energy to ramp up to the highest frequency when a somewhat lower frequency may complete the task in essentially the same amount of time, and return to an idle state.  The highest frequency will use more energy than the moderate frequency, and there may be very real battery savings when this is repeated thousands or millions of times per day.  The trick is to find frequencies that are “fast enough” to create a feeling of snappiness for the user, without constantly ramping up to the highest frequency. I could write a whole other essay on governors, so for now I will leave it at that. If you are really interested, the interactive governor is infinitely tweakable, as described in the Advanced Interactive Governor tweaks thread on xda. For now, it will suffice to say that different governors will behave differently, and have different battery use characteristics.  Therefore, the kernel really does have an impact on battery life.

There are other aspects of the kernel that impact battery life too.  Chief among these is task scheduling, particularly the aspect where tasks are assigned to one CPU core or another.  This means a CPU may be “woken up” to perform a task, or tasks may be packed onto the same core.  Another is hotplugging.  There is an energy cost to put CPU cores on or offline.   On many devices, you will hear about the evils of mpdecision, a closed-source binary from Qualcomm that controls hotplugging and often includes a “touchboost” feature that overrides the CPU governor.  Many custom kernels disable mpdecision and implement a custom hotplugging driver.  My own testing has found that mpdecision and its excessive touchboosting generally do not have a major impact on battery life, and  I have left it enabled in most of my kernels.   In some recent devices, such as the Nexus 6 and the HTC One m9, there is no hotplugging during normal use.  All CPU cores are online.  It can’t be said that task scheduling, hotplugging and touchboost have no impact on battery life.  They clearly do.  It’s just not going to make a huge difference.  If we think of the impact of these optimizations in terms of active drain (% per hour), the change will be relatively small, probably less than one percent per hour, which would be measured in minutes of screen-on time over the course of a day.  I think the impact of these optimizations is more apparent on older devices that are less power efficient and have smaller batteries.

I will mention quickly one more topic that always comes up in discussions of battery life:  undervolting.  Again, undervolting probably made a bigger difference on older devices.  Devices released in the past year or two have become considerably more power efficient, some even have automatic fine tuning and scaling of voltages.  I remember working on msm8960 devices that used the same voltage for every CPU frequency.  In a case like that, undervolting could make quite a difference.  Recent devices run with much lower voltages, and chips are binned with tighter tolerances, leaving less headroom for undervolting and reducing the battery impact of undervolting.  On some devices I offered automatic undervolting, but only for the lowest frequency, which is the most-used frequency.

Much more could be said on this topic, but the main point I wanted to make is that the kernel does, indeed, make a difference in battery life, but the difference is often not as dramatic as some like to think.  From the kernel’s perspective, the CPU governor will have the biggest impact on battery life.  Many of the things that people obsess about do not make a big difference in battery life.  Finally, if you want to judge battery life, take a scientific approach.  Try to use the same conditions when making comparisons, measure carefully, and give it some time.