Google’s Android O Targets Battery Life, Likely With Mixed Results

KONTAK PERKASA FUTURES - Google launched the first beta for Android O yesterday, with a bevy of improvements and changes baked into the operating system. Like Apple, Google’s OS launches go through their own cadence, with some operating systems delivering visible eye candy and visual enhancements, while other versions focus more on improving things under the hood. According to Google, Android O is more akin to the latter kind of update, with meaningful improvements to device security, battery life, and overall stability.
In his comments, Android’s VP of engineering, Dave Burke, said: “We’ve put additional automatic limits on what apps can do in the background, in three main areas: implicit broadcasts, background services, and location updates.” Documentation available online has already shed some light on what these changes are, specifically, but what we’ve found doesn’t always line up with Burke’s comments.

Implicit broadcasts: Not a battery saving issue?

An implicit broadcast is a method for notifying system components that a particular event has occurred if those components have previously registered an interest in that event. Thus, a single event can invoke a theoretically large number of secondary processes. What’s odd about Burke’s comments, however, is that earlier communication from Google on this topic suggested battery life was strictly a secondary concern, and that this was more of an attempt to conserve RAM. That distinction matters, because RAM uses power whether its actively holding data or not. A Google engineer explained Android O’s changes to implicit broadcasts in a forum post back on April 10:

To help understand what is going on, I need to clarify that the purpose of this change is *not* directly related to battery use, but rather to address long-standing issues we have had in the platform where devices that are under memory pressure can get in to bad thrashing states. Very often these states are due to broadcasts: some broadcast or broadcasts are being sent relatively frequently, which a lot of applications are listening to through their manifest (so need to be launched to receive it), but there is not enough RAM to keep all of those app proceses [sic] in cache, so the system ends up continually thrashing through processes each time the broadcast is sent. (Emphasis added)

It is not clear why Google’s messaging on implicit broadcasts is split in this fashion, but clearly some of the company’s own employees don’t see battery life saving as a primary outcome of these changes. Regardless, Android O does put sharper limits on which apps can register for implicit broadcasts.

Background service limitations, device location checks

Google has optimized Android to limit what background applications can do and how they do it. This has been an ongoing process throughout the life of the OS, and Android O is no different. According to Google’s Android O documentation, an app that is shifted from being in the foreground to running in the background is now more restricted in terms of what services it is allowed to use and create. Apps are considered to be in the foreground if they display any visible activity (including when paused), if they have a foreground service, and if they are connected to a foreground service or app. Once an app goes into the background, it can still create and use services for several minutes, after which it is assumed to be in idle mode.
In previous iterations of Android, background applications could create a background service, then promote that service to the foreground. In Android O, apps must use a new method of creating a foreground service, and has five seconds to show a user-visible notification. If it doesn’t call the startForeground() function within five seconds, the app is declared to be non-responsive and the service is killed.

Android is also getting a nifty picture-in-picture mode.

Again, it’s not clear just how much battery life this will save. Some smartphones are more aggressive than others about closing background apps altogether. Samsung tends to be very aggressive about this, to the point that some Samsung smartphones are outperformed in UI responsiveness tests because the Samsung device is re-launching apps from scratch, while other phones are loading them from memory.
Finally, Android O will put limits on how often a device is allowed to check your location when running in the background. If your application is running in the foreground, the app can run its location checks in nearly real-time (at significant cost to your battery life). Once in the background, however, this changes. By default, background apps can only check your location a few times per hour. But there are a number of ways app developers can request more frequent information and Google has suggestions for how to balance location services against power savings. Even here, however, background apps will only be occasionally updated, even if the device receives batched location information (meaning information on the device’s location throughout a given period of time, with said updates still only delivered a few times per hour).

The limits of software

One thing to note is that these limits and requirements will only apply to Android O applications, unless users specifically choose to force them on for other apps compiled for previous versions of Android (as per Google’s documentation). I strongly suspect we will see an equivalent situation emerge for Android that we’ve seen on Windows as well — specifically, what you do with your device and the apps you run control how much power you can conserve in any given situation.
In some cases, with certain bad actors, improvements like this can undoubtedly help a great deal. But from looking over existing Android documentation and conversations between programmers, these improvements seem more likely to boost run time around the edges. How much they help will depend on which apps you use, how you use them, and how much of a workout you give your device on a daily basis.

Source : extremetech.com