Live data from Hacker News

Android vendors, don’t kill my app

dontkillmyapp.com

261–270 of 414 posts

Re: Android vendors, don’t kill my app

#261

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...

It’s there on my Nokia 7+ running Android 9.

Re: Android vendors, don’t kill my app

#262
post #253
post #225

Earlier 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.

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.

Re: Android vendors, don’t kill my app

#263

Earlier 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…

Are fitness tracking apps able to run uninterrupted in your Xiaomi phone? Did you change any relevant settings?

Re: Android vendors, don’t kill my app

#264
post #66

Earlier 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.

Are you referring to Xiaomi devices that are running stock android (part of Android One program)?

Re: Android vendors, don’t kill my app

#265
All I want is a way to protect certain apps from being closed, or at least be the last in line to be closed. That way I can make sure the 1-3 apps I always need are ready to go. And I'm not talking about some instantly loading alarm clock app. I'm talking about complex games or applications that take some time to initialize (Star Trek Timelines, for one).

Re: Android vendors, don’t kill my app

#266

Earlier 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?

Probably a crude way to stop apps from waking themselves every minute.

Re: Android vendors, don’t kill my app

#267
post #193

Earlier 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?)

A bouncer is not a satisfying answer, then I could just use something web-based anyways.

My Android tablet is on a stable WiFi network at home...

Re: Android vendors, don’t kill my app

#268
post #73

Earlier 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?

> 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

#269

Earlier 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)?

No, I have an A1 and it doesn't have these problems. Note 5 definitely did the random alarm fail thing. The Note 5 kills other apps too like step counter or calendar event notifications. Maybe those apps are "badly coded" or whatever, but on a Moto G that sort of shenanigans didn't happen and the same apps worked great with no terrible battery life.

Re: Android vendors, don’t kill my app

#270
post #262
post #253

Earlier 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.

There used to be a hidden list. I was the head of android dev for flock , a team messenger and we had gotten in touch with OnePlus who added us to the whitelist. More details here : https://hackernoon.com/notifications-in-android-are-horribly...

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.

Post reply on HN