To now, Google has done all they can on the system level to make Android run as efficiently as possible. We’ve gotten numerous battery-improving additions to Android over the years which have helped devices deliver better battery life than ever before.
But that’s only on Google’s side. Battery drain could still be possible thanks to things like rogue apps which use way more resources than they are supposed to. Facebook is a perennially notorious offender of this (which is a sad fact considering they’re supposed to have world-class developers, but we digress).
Thankfully, though, Google has found a way to sort of force developers’ apps to play nicely in Android O by limiting apps’ capabilities depending on what state they’re in.
Say, for instance, you “close” Facebook. Prior to Android O, Facebook could still run background services to have its app ping the servers to check for new messages or notifications. While this is normally not an issue, sometimes an app can go haywire during this process and eat up precious system resources even when there is no reason to.
In Android O, this is being addressed by apps having their background status revoked a few minutes after the app is closed. Instead, developers now need to set their server checks up as a scheduled job, so the system can handle that particular job in a more efficient way and ensure it can’t interfere with other background apps or execute more tasks than it needs to. Again, good developers already develop their apps in a way to ensure they’re not encroaching on your device’s resources unnecessarily, but for the few which don’t, this keeps them in line.
Apps can be placed on a “whitelist,” of sorts, when they need to create a background service during special events, such as responding to an incoming SMS/MMS broadcast.
To go further with it, Google is also making a change to the way broadcast listeners are registered. In non-developer speak, the system can “broadcast” certain events, such as when the phone is charging or when a call is incoming. Apps can “listen” for these broadcasts to perform some action when they get the signal. In the case of, say, Netflix, it may not allow you to download movies for offline viewing unless you’re charging your phone and on a WiFi network.
The problem pre-Android O is that if you have multiple apps all listening for the same events and attempting to act on those events at the same time, it could cause trouble. With Android O, event responses are now handled as scheduled jobs, so Android can queue up each task and schedule them accordingly to ensure no one steps on each others’ toes.
Similar changes are coming to location updates for those who rely on GPS-enabled apps. As a foreground app (mostly ones that you are actually running or that forces itself into the foreground by, say, putting a persistent notification in your tray) they have free reign just as they did on Android N, but with Android O, location updates in the background can only be requested a few times per hour, an interval which Google is still tuning but likely won’t change too extremely in either direction.
Think of it all as that intimidating teacher you had on exams day. When class is just getting started and everyone is settling in, go nuts. But when she starts to pass out those test sheets, she’s going to keep her eye on everyone to make sure they’re doing what they’re supposed to be doing and not cheating the system. These apps with background services are like the students, and the Android job scheduler is the teacher who keeps them all in line.
We should note that these new behavioral changes will only apply to apps targeting Android O or higher, though getting developers to make that jump shouldn’t be an issue as they’ll likely want to access all the cool new stuff Android O will enable them to do.