Slashdot Mirror


Top Android Phone Makers Are Killing Useful Background Processes and Breaking 3rd-Party Apps To 'Superficially Improve' Battery Life, Developers Allege (dontkillmyapp.com)

A team of developers has accused several popular smartphone vendors of compromising the functionality of third-party apps and other background processes on their phones in an attempt to "superficially improve" the battery life. The team, Urbandroid, further alleges that these vendors have not correctly implemented Doze mode feature that Google introduced with Android Marshmallow. They also say that Google appears to be doing nothing about it.

Among the worst offenders are, per developers (in descending order): Nokia, OnePlus, Xiaomi, Huawei, Meizu, Sony, Samsung, and HTC.

9 of 162 comments (clear)

  1. Superficially? by Junta · · Score: 3, Interesting

    What, some background process that's responsible for somehow updating the batter meter, resulting in it not going down even though the battery is going down?

    No, that's not the case? Then the battery life is not 'superficially' extended, it is either extended or it isn't. If they claim better battery life as a reason, but they don't actually get battery life, that is not superficially extended, that is flat out incorrect.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  2. Quite annoying by Tomahawk · · Score: 4, Interesting

    This is quite annoying. I found stuff like 'FolderSync', which will allow you to, say, copy the contents of a directory from your phone to your Google Drive automatically every night, would get killed off mid copy as it runs as a background tab.

    Similarly when copying a large file using a file manager, or downloading a large file in the background.

    It's possible to set an app up as an exception, but you have to do this for all applications that you want to be able to run in the background.
    Yes there are some apps that you probably don't want to run, but it's really frustrating when it stops the apps you want to allow run, and you have to go hunting for a setting that has a different name on each phone.

  3. Smaller and Thicker! by Zorro · · Score: 4, Insightful

    Smaller and thicker phones with a decently thick battery.

    We DON'T need a 7 inch phone as thin as a knife!

  4. Moto seems to be good by 140Mandak262Jamuna · · Score: 3, Insightful
    I think it is time to buy only phones that are "Android One" compatible. According to Google, these phones must use stock android with absolutely no modification. And Google will update them without going through the manufacturer.

    Not surprised Nokia being the leader. It is owned by Microsoft now, and Microsoft will always game every benchmark.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  5. So what do we want? by Registered+Coward+v2 · · Score: 3, Insightful

    An open OS that manufacturers can tailor or a standard one controlled by one company to ensure compatibility?

    Manufacturers not letting apps run in the background doing who knows what or allowing them and not having background processes top unexpectedly?

    --
    I'm a consultant - I convert gibberish into cash-flow.
  6. Re:Android is a mess by ilsaloving · · Score: 3, Interesting

    How does anybody manage all of that?

    Wrong question. The real question is why should a user HAVE to manage their phone like a sysadmin?

    It's a phone. It's an *appliance*. If a user is required to manage their phone to such a degree, then there are severe and fundamental flaws in the phone's OS.

    This all stems from the fact that Google gave developers too much control, and developers treated phones as if they were PCs instead of embedded mobile devices. As much as I hate to say it, Apple was right to start with a locked down OS. It is always more difficult to take away permissions and capabilities than it is to gradually give them.

    It's been very well established at this point that developers cannot be trusted to do this properly, so it's up to the OS to be tight-fisted in how apps operate. This is especially true when it comes to limited-resource devices like phones. Now Android is in the completely expected position of trying to lock things down without breaking half the apps on the app store.

  7. Re:I'm fine with this by Goose+In+Orbit · · Score: 3, Insightful

    What about scheduled backups?

    Titanium Backup fails to run any scheduled tasks on my handset - unless the battery "optimisation" for it is turned off... ...run it manually, and it's fine...

  8. Re:Good by svanheulen · · Score: 3, Interesting

    While I agree for most applications, I'm actually having a problem with this behavior on my Samsung phone. I use an always-on VPN which will often lose connection and then not reconnect because the system has stopped/suspended the VPN application. There are options for disabling the Samsung "battery saver" functions for certain applications but even after doing that, it still happens (although not as often).

  9. Android ist running into the same problems... by joh · · Score: 3, Insightful

    ...that Apple tried to avoid to begin with in iOS: Once you allow apps to run in the background, more and more apps want to do that and the bottom line is that the phone is busy all the time and sucks your battery dry and nobody knows why.

    Apple was quite drastic and just didn't allow background tasks with very few exceptions: VoiceIP apps, chat apps and audio apps, also apps are allowed to finish tasks (like downloads) they began while they were in the foreground for max. 5 minutes. Some people think this is too strict, but the sweet spot is somewhere between "no background tasks at all" and "whatever, let apps do what they want", with both extremes probably being utterly wrong.

    You won't find a solution that will satisfy everyone, but as soon as you have phone manufacturers putting up their own policies and hacks nobody knows what will happen with his app when and why and under which Android version. The fact that they seem to NEED their own hacks seems to indicate that Google didn't really solve this problem with Android.