Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android vendors, don’t kill my app

dontkillmyapp.com

Post reply on HN
Print view View original

221–230 of 414 posts

Re: Android vendors, don’t kill my app

#221

Post by finchisko »

Jonnax wrote: post #214
finchisko wrote: post #132

I don't understand why manufacturers are trying to solve problem for user. User has power uninstall app that is draining battery or replace it with something else. There is rating and comment section in app store exactly for this. What they could do instead is to display warning that app is using too much battery, but they SHOULD NEVER KILL AN APP. It may sound radical, but only countermeasure we developers have is t…

The user experience is more important than a app developer's need. Users want better battery life. They don't want a app using it up. Feel free to block the installation of your app on devices that you feel unfairly target background apps, they'll just use a different application.

>Users want better battery life. They don't want a app using it up.

Everybody wants better battery life, but also their alarm app to wake them up, or tracking app to record their runs in the background, receive notification when there is new email or im message, etc. And these functionalities get disrupted by excessive battery management (killing apps in the background).

Somebody thinking he knows what users want and making decision based on this assumption (without really asking user) is exactly what brought us here. We are not all the same, somebody can have bit different priorities then you.

Re: Android vendors, don’t kill my app

#222

Post by spalt »

"Doze" is a nightmare for apps that need reliable GPS readings.. the only real solution is a service that polls continually to get the GPS when the screen is on so that when the screen is off it can use it to do various background tasks (and of course, it ends up not being super accurate as when the screen is off the user is typically moving, which is when you'd want the GPS to be accurate). This ends up using more energy than would have been saved if the GPS wasn't available periodically when the screen is off! It's totally ridiculous..

Re: Android vendors, don’t kill my app

#223

Post by faceplanted »

sethammons wrote: post #208
whouweling wrote: post #126

We are running a (very niche) platform + app for people with special needs, where accurate and offline alarms are necessary: this is a big problem for us. I think about 1/3 of all our support requests are about the app being killed in the background on specific phones. The part of the app that does the actual scheduling of the alarms is a big mess with lots of device & API level exceptions. Debugging alarm problems i…

What about changing your app to a service that you host that calls their phone instead of an alarm?

He did specifically just say they have to work offline.

Re: Android vendors, don’t kill my app

#224

Post by shittyadmin »

PunchTornado wrote: post #211
masklinn wrote: post #181

Earlier quoted context omitted.

Did you even bother reading the complaints? These "background killers" kill background applications the user wants to run and has specifically asked for e.g. alarms, health/fitness trackers, …, usually in the most harmful way possible (e.g. straight kill -9) meaning the application can't even tell the user what the issue is, and with complex steps users have to take (possibly repeatedly) to whitelist specific applica…

been using android since forever. Now I'm on a s8+. I never had a case like this. maybe I didn't noticed it. But my alarm always went on like it should. my music always played. is this a bug that sometimes happens? how rare is it?

Seems it's mainly an issue with Nokia devices, the other manufacturers were minor problems in comparisons.

Re: Android vendors, don’t kill my app

#225

Post by Yizahi »

me551ah wrote: post #138
yason wrote: post #129

Killing apps is a good thing . There have been battery saver programs since the very beginning of early Android versions to kill of connectivity and clean up running apps. When Android now supports some of that natively and vendors too, even more aggressively, this is just responding to users' needs. There is a quite clear usage pattern to support this behaviour: unless I explicitly say so, I don't want apps on their…

Killing background tasks is great and Android does that automatically to save battery usage. But these manufacturers have implemented their own functionality on top of Android which cripples even critical messaging applications like WhatsApp, Slack, Gmail by not delivering Instant Messages notifications instantly.

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 sometimes start it on phone.

I'm going to generalize and say that probably some apps are simple bad and need to be fixed instead of granting them exceptions and allowing to be battery hogs.

Re: Android vendors, don’t kill my app

#226

Post by finchisko »

Jonnax wrote: post #214
finchisko wrote: post #132

I don't understand why manufacturers are trying to solve problem for user. User has power uninstall app that is draining battery or replace it with something else. There is rating and comment section in app store exactly for this. What they could do instead is to display warning that app is using too much battery, but they SHOULD NEVER KILL AN APP. It may sound radical, but only countermeasure we developers have is t…

The user experience is more important than a app developer's need. Users want better battery life. They don't want a app using it up. Feel free to block the installation of your app on devices that you feel unfairly target background apps, they'll just use a different application.

>Feel free to block the installation of your app on devices that you feel unfairly target background apps, they'll just use a different application. reply

with some devices you just can't find alternative that would work reliably in the background for example. Imagine sport tracker, that needs to record locations even when in background. You cannot just use another app, because any sport app could get killed due excessive power management.

Favoring some apps by manufacturers putting them on a whitelist to prevent them from being killed should be considered as unfair practice (potentially illegal).

Re: Android vendors, don’t kill my app

#227

Post by dithering »

anc84 wrote: post #193
CodeWriter23 wrote: post #127

Earlier quoted context omitted.

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?

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

Re: Android vendors, don’t kill my app

#228

Post by dorfsmay »

lukevp wrote: post #215
masklinn wrote: post #209

Earlier quoted context omitted.

As TFA notes (in the Nokia section, possibly others): > This app kills apps in the most brutal way we have seen so far among Android vendors. You can't detect that your application was kill -9'd. I don't think you can detect that "PowerSavingAppG3" is running either (I'd guess it's running as root and you're not), so you can't even infer from its existence that your application will be traumatically killed in short o…

I think you are reversing what the parent comment meant. You can continually write to the sandboxed filesystem of your app, say write the current timestamp every 10 seconds, and a status of if the app exited gracefully (which you can control). Then when restarting the app you check if there was a timestamp written in the last say 2 hours and no graceful exit then you know the app was terminated and can explain that t…

How do you differentiate an apps crash from an OS forceful kill?

Both would show a last good status and no good exit.

Re: Android vendors, don’t kill my app

#230

Post by Yizahi »

mosselman wrote: post #43

First I though "Is Nokia bad or good? Then I saw 'bad vendor score'" so I figured they are the worst. Then I got confused about all the vendors having the same score, but a different colour. Then I saw that some of the circles are slightly darker than the others... This type of visual communication hurts my brain too much.

It seems that just as bad apps they are trying to shield their website is also badly written and the simple picture of poop is linked from whatever of the 7 third-party sites with spying javascript code they are using and is blocked by adblock. Circles for me too.
Post reply on HN