That's why I'm happy with Android One (which many Nokia phones come with these days).
Apparently the app that kills other apps comes installed on Nokias with Android One as well. https://www.reddit.com/r/Nokia/comments/actk7z/android_one_p...
Android vendors, don’t kill my app
261–270 of 414 posts
Re: Android vendors, don’t kill my app
#262Earlier quoted context omitted.
Just as an example, only chat/messenger apps on my Oneplus with saver enabled (default): - Skype - always killed - Slack - always killed - Whatsapp - sometimes killed, rarely - Telegram - never killed - FB Messenger - never killed All these are fully featured apps with tons of different functionality. Telegram and FBM never ever trigger "this app is draining your battery" while Skype triggers it regularly when I some…
Those apps are explicitly whitelisted by OnePlus. There's nothing to "fix" they're by the app developer, because the killing algorithm chooses based on app name, not app battery consumption. Facebook can kill your whole battery and you'll never get a warning.
Re: Android vendors, don’t kill my app
#263Earlier quoted context omitted.
So how do you propose to write a sleep tracking app that doesn't run a background process for longer than 20 minutes?
I have a Xiaomi and oneplus phone, neither of them have ever closed a background app so I dunno what you are talking about, but if phones are doing that then, yea fair enough thats a problem. The wording in the linked website is talking more specifically about cpu limits, which is how most os manage background resources, whats the problem with that? Sleep tracking is a good example you should use an event system, but…
Re: Android vendors, don’t kill my app
#264Earlier quoted context omitted.
No, you don't need a background task for alarms. There is a JobScheduler API for that. The aggressive battery settings of most vendors only interfere with badly coded apps to begin with, apps that use background tasks when they should be using more appropriate APIs.
On some Xiaomi devices the stock alarm clock - the Google one - regularly fails to trigger alarms. If Google themselves cannot code an Android alarm clock that works with these aggressive battery saving anti-features there's little hope for anyone else.
Re: Android vendors, don’t kill my app
#265Re: Android vendors, don’t kill my app
#266Earlier quoted context omitted.
It does - the one that works properly is https://developer.android.com/reference/android/app/AlarmMan... However, the implementations of the API are questionable. Some calls to that API on some OEMs device round alarms to the nearest minute, some to the nearest ten minutes.
> Some calls to that API on some OEMs device round alarms to the nearest minute, some to the nearest ten minutes. WHY? What benefit does that serve?
Re: Android vendors, don’t kill my app
#267Earlier quoted context omitted.
Can I run XMPP or IRC on an iphone by now or does it still only receive messages when foregrounded?
"Use a bouncer" might be the answer there. All engineering is compromise, and needing a bit more compromise to support legacy applications is not unreasonable. (In fact, why are you running a stream-oriented application over such an unreliable connection at all?)
My Android tablet is on a stable WiFi network at home...
Re: Android vendors, don’t kill my app
#268Earlier quoted context omitted.
Isn't it also the consequence of taking the control away from the user? Why can't I whitelist which applications I want to allow to run in the background? Why do I still have to grant an application all the permissions it requests when I install it instead of being able to turn them on or off individually? By dumbing things down that way Google created this situation IMO, it's bad from a quality, usability and privac…
No, it’s the consequence of permitting background tasks at will. Apple took some heat, and there is learning curve associated with doing it their way, but they actually thought it through and created an energy-efficient architecture that addresses common use cases. And apps that don’t fit those use cases - what are they doing with your device?
What I, the owner of my device, have directed them to do.
Apple's approach makes easy things difficult (because one must use their APIs) and difficult things impossible (because Apple have decided that purchasers of their devices shouldn't be permitted to do things Apple wishes them not to do).
I want a general-purpose computer that I own & control in my pocket, not some stripped-down communicator owned & control by someone else.
Re: Android vendors, don’t kill my app
#269Earlier quoted context omitted.
On some Xiaomi devices the stock alarm clock - the Google one - regularly fails to trigger alarms. If Google themselves cannot code an Android alarm clock that works with these aggressive battery saving anti-features there's little hope for anyone else.
Are you referring to Xiaomi devices that are running stock android (part of Android One program)?
Re: Android vendors, don’t kill my app
#270Earlier quoted context omitted.
Those apps are explicitly whitelisted by OnePlus. There's nothing to "fix" they're by the app developer, because the killing algorithm chooses based on app name, not app battery consumption. Facebook can kill your whole battery and you'll never get a warning.
So you are saying that behind visible list of apps that are either "optimized" or excluded there is another hidden list where app that is "optimized" could be actually excluded? Ok, that can be a working hypothesis. Why is Skype not excluded the same way then? Or Slack? Millions use them and MS surely has money to promote their app this way. Why Whatsapp is not excluded? It's owned by FB.
Though they were moving away from that model to a model where apps alive for more than a certain time interval in background were killed. So apps which you use the most heavily are more likely to be penalized.