Oreo features you'll love: Background execution limits

Your Android phone will let you do many things at once, even though all of them might not be on your screen. Besides system processes that can do things like checking your location or seeing if you have any new email, apps can be opened and then be left to run in the background while we are doing something else.

A good example would be when you open your favorite music player and cue up a playlist to listen to while you check out Facebook or do a little web browsing. The music app is running in the background, doing its thing while you're looking at something else.

But some apps can be sent completely to the background. In our example of Oreo's Background execution limits, the music player is not on the screen and running as a background app, but it's still interacting with us and playing music. Other apps that we've opened and switched away from should be treated differently because we're not doing anything with them.

This can have an effect on the limited resources of your phone. Apps running can use RAM and take processing time away from other apps that need a turn or even the app you're currently using in the foreground (what you see on your screen.) While Android has always had some restrictions on what an app can do while it's not on your screen, Oreo brings smarter limitations to help conserve system resources and battery life by determining when an app is really in the background and can be idle, then keeping it quiet but ready for when you want to use it again.

While this video is Android Nougat specific, it does a great job explaining how background services can affect the apps you're actively using and ways to keep things in check.

What's new or changed in Oreo

  • Background Service Limitations. The system now does a few routine checks to see if an app can be considered as being in the background. It checks to see that the app or any of the activities (things an app can do or initiate) aren't visible on the screen. It then checks to see if another app is connected to it or uses any information from it, and finally, it checks for a few high-priority services like being able to act as a keyboard or if it is actively listening for voice input.

If none of these things are true the app is considered as running in the background. When an app is first considered to be in the background, it has a short window where it's allowed to do its thing in case it needs to start something that would move it to a foreground app or service. Once that time is over the app is forced to be idle. Idle apps are also given short windows periodically in case they need to connect or start services, but other than those times it sits and uses very little resources until we switch back to it.

  • Broadcast Limitations. Broadcasts are done by the system when specific events happen. When you switch your phone in and out of Airplane Mode, for example, a broadcast is sent to let apps know what happened. Developers can set up their apps to listen for specific broadcasts and write code so the apps do something when they happen. If an app is listening for broadcasts, every time one is sent the app uses system resources to see if any action is needed.

Apps built for Oreo can no longer register to listen for broadcast messages that don't directly target the app itself unless they are started and running (not in the background according to the rules above). These changes started with Android N, and changes in Oreo are a bit more strict. Because this could limit what a developer might want to do, new tools to schedule specific jobs using their own apps processes have been developed. There are also a few broadcasts exempt from all of this, like when the time zone changes or the phone was plugged into the charger. Every app can listen for those, and react accordingly.

By limiting how an app can listen and what it can listen for, apps that have been designated as being in the background won't wake up to see if they need to do anything as often. "Sleeping" apps use far fewer resources.

Why you'll love it

We want our phones to do a lot of things. But no matter what we're asking it to do, while we are looking at the screen we expect things to be smooth and responsive.

We've all felt the frustration that comes with keyboard lag once in a while, and it's not a good experience. By keeping a tighter leash on the apps we're not looking at, memory, processing power, and battery life is used more efficiently and we'll see less of things like keyboard lag. The end user — that's us! — doesn't have to do anything here because these changes are part of the system. Even better, older apps that weren't built with Oreo in mind can be set to follow these rules from the apps setting page.

Changes like this get combined with the great hardware we see every year and mean your phone can do the things you ask of it even better!

Jerry Hildenbrand
Senior Editor — Google Ecosystem

Jerry is an amateur woodworker and struggling shade tree mechanic. There's nothing he can't take apart, but many things he can't reassemble. You'll find him writing and speaking his loud opinion on Android Central and occasionally on Twitter.

  • I am still betting it's Orangesicle not Oreo.
  • This was my thought also.
  • I cannot wait for the Essential phone to get updated with 8.0.
  • Same here.
  • I have a feeling this is just going to mean a LOT more app refreshes. Google already started that trend with their overly-aggressive RAM management on the Pixel. I'd rather have my apps stay in memory like they do on the OnePlus 5.
  • Maybe they'll do something like how the iPhone saves it state?
  • The iPhone uses up the ROM for storing cache files in compressed form, hence you find iPhone users always complaining about lack of storage.
    Also, this isn't possible on Android because of the fragmentation. While this is completely fine on a 64Gb phone but we still do have 16Gb phones.
  • If I have the choice to assign apps to this restriction then great but if its like iPhone where all apps are restricted then this is crap.
  • Orellete
  • O is for Orange.
  • I love how they take distance on the fact that the device are "crippled" with "lots" memory trashing.. Like this is not the system they built.. Like this issue is new to android system. I love it. Some random unknown force as set things like that, and the mighty Google will fix it for us. Or will they ?
  • Thanks Jerry. Good stuff as always. This should help battery life I hope. My one concern is for apps that need to run in the background. An example is the Life360 app me and my family use. It's an app that lets us keep track of each other's location. I wonder how this app will behave if I were to bring it up and check my wife's location, and Android O decided that Life360 was running in the background and stopped it from providing location details. I understand there need to be trade-offs (we can't have everything running always and still have perfect battery life), but I wonder how apps that need to be running in the background - truly - will be handled..
  • Man, is Facebook going to be jacked! lol. Serious memory hog, along with Messenger.
    Can't wait to see this, if I ever get it on my S7E, maybe too old...
  • This article is quite wrong. The background limits work ONLY for apps that got updated to target Android O. The reason is for backward compatibility.
    Apps can still work in the background as before, as long as they target pre-Android-O.
    If they target Android-O and above, in order to still reliably work in the background, they need to run "in the foreground" (foreground service is one that shows a notification).
    This actually is bad for users: you either have the same behavior as before, or see a lot more annoying notifications, just to tell you that they work in the background.
    I don't think that hiding a notification lets the app still work fine in the background, so I think you are left with a lot of notifications, in case the apps target Android O.
    The only limit that apply to ALL Android apps, is the GPS polling limitation. Each app can poll up to just once in 15 minutes or so, if it's in the background. Only foreground apps can poll more often.
  • Nope . Users still will be able to apply restrictions on background apps by going in setting-> battery optimastion .
    Ultimately devs will have to make their apps compatible to android o apis'
  • Incorrect. The battery optimizations were there before Android O . It belongs to other optimization behavior ("Doze"), which has nothing to do with it.
    About compatibility, you don't have to set targetSdk to Android O to make it work there. Not only that, but apps can use the latest Android API, without the need to change targetSdk
  • Not if it comes at having to stare at persistent notifications. I'll pass.
  • Android O is supposed to have way more control of notifications. You can choose what types, etc that they can display.
  • Samsung should be pushing out Android O around this time next year, most likely with the Note 9 gets released.
  • Yup, and that is part of the reason I left Sammy. That and battery life and slowdowns over time. They used to be my brand, but got sick of their crap.
  • Unlikely that Samsung will take that long. @Windsailor frequently posts about his/her AT&T Samsung S7 taking 170 days to update, that's less than half a year, not a whole year.
  • When?
  • Notifications are already delayed with power doze on apps like GMail. I wonder more hours they will be delayed with background tasks limited.