Yesterday at I/O Google had an interesting talk called Background Check and Other Insights into the Android Operating System Framework. It's a long name, but really it's about improving battery life in Android. It went on at great length as to how, exactly, the team plans on doing that, and it's quite worth a watch. We have the video here, but if you don't have the half-hour to check it out, then you are welcome to read below.

The central methodology Google is using to try to improve things is the idea of visibility. When something is running in the background and doing a ton of stuff like calling your location at quick intervals, it results in battery drain. So now Google wants to change how things happen in the background, by ensuring that free-running background services aren't sucking your battery dry. Background apps will be pushed out of memory when they leave the foreground, and requests for things like location or WiFi happening in the background will only occasionally see new information from Android. Applications that would otherwise receive broadcasts also might not wake up unless they are given an explicit call to do so in the broadcast, although there are some exceptions. Apps can still get around this by being foregrounded in some way, but now that will be something visible that the user is aware of.

This focus on visibility for apps will also mean developers will have to make decisions about what is really better to the user. If doing an ongoing notification as a means of bypassing the stuff above would confuse a user, is that really the right thing for them to do in that case? Other tools can be used to schedule your tasks ahead of time or to wait for events like the job intent service that developers can use in both pre and post-O environments. Jobs and alarms also allow the OS to defer. So, if something happens that would trigger a bunch of other apps to wake up, like a new picture being taken, that can be passed to those apps one at a time after a delay. That way the user doesn't suddenly have a ton of performance issues and drain out of nowhere.

Basically, Google wants to solve some of the problems with battery life by defining bad behaviors for developers, like persistent background services or accidental leaks to the background of typically foregrounded activities, and make it clear that things have to be done the right way going forward or their stuff won't work. But it's also giving them new tools and choices for how to best accomplish the things they need to do. The new features in the Play Console and in Android Studio should also help developers be aware of when they are making these mistakes so that they can be fixed. It's a matter of visibility for the developers as well as visibility for the users. To paraphrase Steve Balmer: Visibility, visibility, visibility.

A significant user-facing change of this visibility mindset is a new battery menu in O, with a focus on actionable interaction. Instead of just seeing stuff like Screen and Google Play Services next to a number that they won't understand, now users will be given ways of interacting with that data if they don't like it, and can better see how they are using applications without needing to do a bunch of mental calculations. So, when a user has a problem with their expectations of battery performance and goes looking to see what might be causing it, they are more likely to find what caused it, understand what it means, and take action about it.

All of these changes are in pursuit of Google's holy grail: multi-day battery life. Right now the tools in software aren't all there, but these are steps that can take us in that direction.

Source: Google (1, 2, 3)