Regardless of how large the batteries in our portable electronics are, or how efficiently their SoCs power them, we never seem to have “enough” power. Thankfully, Android lets you see what apps and processes are using your battery, so you can take corrective measures and (ideally) get the most out of the limited mAhs in your LiPo cell.
Take a look at your own stats. Open Settings and tap on Battery. Depending on which version of Android you’re running and how heavily your OEM has skinned your device, you’ll probably see a chart with a list of apps and processes beneath it. The heaviest power users are listed at the top with the percentage of your battery that each is responsible for gobbling up.
As I’m sitting here, I’ve got 88% battery on my Nexus 5, the screen is responsible for 3% of that, Automatic is at 3% as well, but then two “mystery services” pop up: “Android OS” and “Android System” (2% and 1% respectively). What are they, and why do they often consume so much battery life?
“Android OS” and “Android System”
1% and 2% are nothing to be worried about, but that’s just what my device is reporting now. By the end of the day those numbers will be much different. Some users are even reporting that either of those two processes make up 30- or 40-percent of the battery usage on their phone or tablet. Something’s not right there, but what is it?
An operating system is a pretty big “thing”. It’s got tens of thousands of lines of code, acts as an abstraction layer between hardware and software, and often includes a bunch of apps and services all bundled together. Microsoft Windows, for example, gives you the environment that you need to be able to run applications and get things done. It contains the framework into which drivers for specific pieces of hardware hook (video card, keyboard and mouse, audio chip, network adapter, etc.) as well as the interface (whether graphical or command-line, or both) through which you interact with software, and launch applications.
Before Windows completely “replaced” DOS, I used a word processor called WordPerfect. Version 6 was an amazing application. It looked like a Windows application (almost), it felt like a Windows application (almost), but it wasn’t a Windows application, it was a DOS application. As such, it had to be more “self-contained” than programs written for Windows.
I had a really cool dot-matrix printer which could even print color. Color! Remember, this was back when even most businesses had to send color print jobs off to an out-of-house print shop. Sometimes I miss the clicking and buzzing of that NEC Pinwriter. It had drivers for Windows that let me print anything I wanted using its full-color wizardry. Unfortunately, once I fired up WordPerfect, I lost the ability to print in color. Why? DOS programs required their own print drivers, and at the time the driver for my printer didn’t support color.
“What does all this have to do with Android, Joe?!”
Hold your horses, I’m getting there! Gosh! Windows had drivers for all your hardware already installed and configured. Rather, when you got a new piece of hardware, you installed its driver into Windows.
Programs written for Windows didn’t have to include support for all those components individually, they just had to hook into what your installation of Windows offered. This let developers focus on the solution they were tasked with. In this case, developers could focus on making a better word processor, and didn’t have to worry about writing print drivers for the thousands of printers on the market. Games didn’t have to include audio drivers for various sound cards and video drivers for various video cards, they just used whatever Windows gave them.
That’s how modern operating systems work. Applied to Android, apps no longer have to write code to talk to your GPS chip, your camera’s LED flash (or even the camera itself), or any of the other hardware components in your phone or tablet. Android provides an API through which apps can talk to these devices. The further your hardware is abstracted from the apps you run, the less app development time is needed. Apps can be written faster, better, and smaller because the operating system takes care of the heavy lifting.
That brings us back to “Android OS” and “Android System” in your battery report.
When an app wants to know where you are, it asks Android. When your battery stats are reported, it’s “Android” that used the battery to determine your location, not Facebook, Twitter, Google+, Waze, or whatever other geo-aware app you were using. Location awareness is just one example. We could talk about apps that use data from the barometer, pedometer, light sensor, magnetometer, etc,. but geo-location is probably the easiest to talk about to illustrate the concept.
Everything is behaving as it should be, but your battery report isn’t being as helpful as you’d like it to be. You want to know what apps are using more of your battery than you’d like them to, then put pressure on their developers to fix it, right? We’re not there just yet, and even with the advancements in battery reporting coming in Android 5.0 Lollipop, tracking down the power gobbling culprits isn’t quite as clear cut as we’d like it to be. Not yet anyway, but we’re making progress!