Battery is the hottest topic these days — figuratively, speaking of course. But another battery-related topic does not get as much attention as the issue deserves: battery life instability on Android.
Starting off with a very broad and general brush, Android and battery life are not the best of buddies. If you ask any average user if they are content with the battery life their phone offers beyond the honeymoon period, chances are that they do see a lot of room for improvement… At least depending on what day of the day it is. And they would not be wrong, because in a nutshell, battery life on Android is one of the most volatile and unstable aspects of the OS that has continued to exist from its infant days. You can have days where your phone does not break a sweat, and in the same vein, you can have days where your phone spends most of the day hugging a wall. And there often is no clear tip-over point where you shift from one state to the other.
The variance in battery life in day to day usage, for the same user and often the same use-cases, is what causes bewilderment. A good phone can have good battery life for a few weeks, and then suddenly start acting up. Most of us would have also faced inexplicable wakelocks, after which we spend minutes, hours or even days figuring out the cause for this unexpected drain. We often see the biggest draw being Google Play Services, but the services act as a framework which other apps and services call upon to provide data and offer their functionality. Play Services draws most of the ire, while in many instances it is just working as the messenger who gets shot. But since it is so opaque in its working from an end-user perspective, there is no easy to figure out just what is causing Play Services to go into overdrive, or if it is indeed Play Services itself.
The issue then moves on to rogue apps that we may have installed. It is more of a problem for the average user, ones who do not pay microscopic attention to what apps they are downloading, which apps have gotten updated, and how the app manages to do things it claims to do. For example, an app could still continue to use the dated practice of periodic polling instead of the now-standard GCM push, and that will definitely have an effect on your battery in some capacity. The end user does not know, or care enough, about this. But the result does affect him, disturbing his perception of Android phones and their battery life when in reality it could be just one poorly coded app.
Issues do not remain solely with rogue apps that are newly installed. Some older apps go rogue when they are updated, adding in features that no one asked for and eating up resources that could be used elsewhere. A prime example of this behavior is Snapchat with its Discover update, which caused widespread battery and data consumption issues during its initial rollout. As the feature was mandatory and not opt-in, the average consumer who auto-updates his apps would have little clue as to what is happening. What he is instead presented with is a huge data bill and noticeably worse battery life with no clue as to what is happening. Unless the user proactively tries to find out the cause, he shall be condemned to remain oblivious of the true culprit and instead would blame the whole OS.
These reasons are from the app end of things, but what happens when critical parts of the OS are to blame? The initial builds of 5.0 Lollipop come to mind when we talk of messed up releases. Poor memory management forced users to reboot their phones frequently, which in turn is a process that shaves off a few precious percentages of juice in mere minutes. Then there’s the Mobile Radio Active Bug which prevented phones from going to sleep. Overall, the update was a step down from the stable days of Android 4.4 Kitkat, and you could read about poor battery life practically everywhere on the forums. Android 6.0 Marshmallow brought in Doze to ease off the battery woes, but the strict requirements for Doze to come into play limited its ability to increase short term standby or active use time. Initially Doze showed noticeable results only when the device is left stationary for long periods of time, but the improved Doze in Android 7.0 Nougat relaxes the requirements to push forth a lenient version of Doze early-on in the screen-off state. Once the device becomes stationary for a while and the requirements for strict Doze are met, the previous variant would kick in. As Nougat is still yet to gain mainstream consumer traction, the perception of the average is unaffected by this update that they have not experienced. This is all from an AOSP point of view, because with custom skins from OEM, the number of inconsistencies keeps on mounting.
A lot of the gains that we see in battery life are from advancements in other pieces of technology evolving better than the OS. It is a complex equation with a lot of variables — other variables like screen tech, SoC power consumption and even increase in physical capacity, all combined give us marginally better life each year (if that). The improvements in these factors often need to compensate for the negative effects that the OS, rogue apps and manufacturer additions do to the usable life of the phone.
So what can be possibly done to fix this issue?
There is no easy, one-word answer to this multi-faceted problem. Instead, a shift in approach could help lower the variability in battery life or at least help regular users understand what is going on. Transparency with the workings of Google Play Services will aid in figuring out where the root problem lies. The identification of the issue solves a good part of the headache, since users (who care) will then be able to find solutions to their specific issue rather than try troubleshooting the umbrella problem of Play Services draining their battery. A breakdown of the functioning of Play Services, with an estimate of battery usage for its specific functionality and what called for this functionality can help in case the infamous item goes rogue. Pinpointing the offender would be the ideal case solution, and improved transparency would be a good start in achieving that goal. Granularity in the headings that the OS currently reports under will also work towards the locating trouble points — wide umbrella terms just do not cut it anymore in an OS so complex.
Another approach could be Google incorporating a way to easily identify and interpret wakelocks within AOSP. Figuring out what is misbehaving on a phone should not be a process limited to power users only. Needing root (which in turn needs a custom recovery, often a custom kernel and also an unlockable bootloader — not to mention the unfair loss of warranty) to figure out what is not letting your phone sleep and achieve that state of Zen Doze is a strong dissuading factor to the users who simply want to know what is causing the battery issues on their phone. Having to flash modifications like Amplify Xposed Module to solve these issues is something we are very used to at XDA, but even OEMs are focusing on battery life and managing background services in their latest releases. In fact, Google could take a page out of some of the bloated skins’ books, because a few of them provide better app monitoring and issue identification, as well as notifications when the system spots a major offender in real time. There are settings which help users understand what is draining their battery life beyond the oh-so-very-useful “Android OS” header, and there are tips on how the effect of the drain could be minimized — not to mention an ever-increasing number of battery saving options, such as lowering resolution or switching performance mode. It is not perfect in implementation, but something is better than nothing, and it’s appreciated if and when it is done right.
All of these suggestions involve informing and empowering the user rather than restraining the culprits. We do know that Google is laying the foundation to tackling background services, slowly beginning with Android Nougat. But it could be a long time before we see tangible results across the ecosystem. We’d like to end on the note that Android is now a mature OS. The problems should ideally not exist in the first place. But since they do, it is only fair that better tools are provided to troubleshoot. Officially.
What are your thoughts on Android’s battery issues, and the current methods to troubleshoot them? Let us know in the comments below!
from xda-developers http://ift.tt/2cbnZLq
via IFTTT
Aucun commentaire:
Enregistrer un commentaire