With every new Android release comes a new feature aimed at improving battery life, and Oreo is not different. Thankfully though, this year we're not getting yet another iteration of Doze. Instead, background limits make Android behave more like iOS in one particular area. In theory, at least.
Background execution limits ensure that rogue apps won't eat up your entire battery in a few hours, by doing too many things in the background when you're not actively using them. As a consequence, performance for low-end devices shouldn't degrade as badly when you're multitasking.
It all sounds nice enough, but there's a huge catch. By default, background execution limits are only enabled for apps that target Android 8.0. If a developer wants to get around this, their apps simply need to target a lower version of Android, and that's it - said apps will still be able to do as much background stuff as before. Since apps can be uploaded to the Play Store even if they don't target Oreo, this is a bit of a blunt knife for now.
There is a workaround for apps that don't target Android 8.0, however. If you find that one of your apps is misbehaving while it's in the background, but you don't want to uninstall it, you can manually enforce background execution limits on it through the Battery menu in Settings. The option to turn off background activity is placed in a way that lets you immediately take action if you see an app that you haven't actively used showing up in the battery stats.
In a similar fashion to background execution limits, Oreo wants to help your battery life by limiting how often any app can ask for your location. Actively locating you is one of the most battery-consuming things a phone can do, since by default it uses the GPS as well as Wi-Fi, mobile and Bluetooth radios. So naturally if an app keeps asking for your location over and over again, your battery level will go down the drain quickly.
In Oreo, apps can receive location updates only a few times per hour while they're in the background. The foreground app behavior is the same as in Android 7.1. Unlike background execution limits, the location limits are automatically enforced in Oreo for every single app, no exceptions.
Here's an Android-related truism: if you're interested in keeping your software up-to-date and you don't own a Pixel or Nexus device, you're probably annoyed by how slowly your device's maker is pushing new OS versions to you. Even if you do have one of Google's devices, if you'd like software support for big updates to extend past the current two-year window, you're out of luck. Project Treble could change all of that. Huge emphasis on 'could'.
This is definitely not the first time Google promises swifter updates, and we've been burned many times before so we're taking a cautious approach to Treble. However, since it's basically a rebuilding of the entire core of the OS, it might just work out. In time, that is.
See, rumor has it that the reason why even Google itself only promises two years of big Android updates for its Pixel line has nothing to do with the company wanting to sell you new models. Instead, the blame may lie more with chipset makers such as Qualcomm. To understand how the current update process works, take a look at the image below.
Qualcomm and other chip makers take every new Android release, once it's finalized, and add optimized silicon-specific code. It's important to note that these bits are proprietary and need to be reworked for every single Android iteration. Then the chip vendor hands over the resulting Board Support Package (BSP) to your phone's manufacturer, which adds its own bloat alongside any carrier requirements.
Ignoring the various skins that OEMs add, the big issue is that SoC makers don't seem to think creating BSPs for their chips for more than two years is really necessary. So they don't. When they end support in this way, there's absolutely nothing your device maker can do about the situation, it's simply impossible for it to issue any more updates from that point on.
Treble theoretically fixes this by making it possible for OEMs to create updates even if the silicon vendor stops supporting a certain chipset with new BSPs. That's because thanks to Treble the device-specific, lower-level software written by SoC makers is separated from the Android OS framework through a new vendor interface. Now the framework can be updated independently of the chip maker's layer. So the Qualcomms of the world no longer have to create a reworked implementation of their low-level software for each new Android version - OEMs can simply choose to use the previous one.
Ready for a huge caveat? Project Treble will only live on devices that launch running Android 8.0 Oreo. The only exceptions at the moment are Google's original Pixels from 2016. There may be some other device makers that choose to implement Treble through Oreo software updates, but don't get your hopes up. If what Treble does is important to you, make sure you either have a Pixel or your next device runs Oreo from day one.