Live data from Hacker News

Android vendors, don’t kill my app

dontkillmyapp.com

91–100 of 414 posts

Re: Android vendors, don’t kill my app

#91
post #3

I actually like the move to kill background tasks. Don't get me wrong I think they're great when they're needed. But if I only installed the app because the mobile site is crippled I don't want it to destroy my battery polling for content changes when I only open the app once in a blue moon.

Yes this is very true. Some apps like Truecaller just destroy the battery like there is no tommorow. Most other app including some games keep running just to tell me when it's time to collect my mystery box.

Point being the majority of the apps are badly coded to poll or drain battery, send unnecessary notifications.

This reminds me of the popup blocker thing in web browsers. While there were some legitimate uses most of the time it's abused so every browser blocked it.

Re: Android vendors, don’t kill my app

#92

I'm confused. Is this something that occurs all the time, or only when I turn on Battery Saver? Because I love Battery Saver mode. Unless you're a communications app (messaging, phone, email) I don't need your app running when I'm not actively using it.

Most brands of phone do this all the time, and do it even more aggressively in battery saver mode.

Re: Android vendors, don’t kill my app

#94

The solution to this should be user experience billing . If your app wants to run a background service which degrades the users battery, you are degrading the user experience for that user, and all the other apps they use . Another app on the same phone which is very power efficient will still not get used if the battery is dead! App developers who use up the phone battery should be required to compensate those who u…

> Apps will put money in the pot (subtracted from ad revenue)

At this point you discover it costs more to render an ad to the user (and especially to download it) than it pays the app developer ...

Re: Android vendors, don’t kill my app

#95
post #77
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…

And yeah, the permissions model in Android vs Apple is different, but multi tasking in particular feels the same. i.e. Apple has fine grained permissions on demand for contacts, microphone, camera, location, etc, and requires that all apps gracefully degrade when permissions is denied. But for multitasking there isn’t really any fine grained permissions - as long as the app is doing a whitelisted task in the backgrou…

As I understand it, on iOS third part apps don’t actually do any tasks in the background, most such services are actually implemented by platform services provided by Apple that the third part apps request or subscribe to. So for example apps request an Apple service to do a background download on their behalf. Or the app subscribes to a notification feed that wakes it up when triggered to handle the notification, but the app doesn't do a download or wait for notifications itself.

Very often on iOS when you see a notification 'from an app' or something in the background is completed 'by an app', in fact the app didn't do any of it. This means fine grained permissions for background processing aren't really an issue on iOS, because such behavior is managed and guaranteed by Apple. It only matters when there's a security or privacy implication.

This is why background activities came so much later to iOS, because Apple had to very carefully think through and implement all the background services apps would require in an efficient and secure way.

EDIT: To be clear there are some exceptions but I'm not sure exactly what they are.

Re: Android vendors, don’t kill my app

#97
Not sure if the complaint here is simply from developers of badly designed apps?

I didn't do much Android development, but last year I had to develop a small app doing a continuous background task.

Yes, it is hard to do that in Android (it seems). But you are supposed to use all sorts of other mechanisms that Android provides. Like for an alarm clock, I guess you tell some system service to play the sound and then go back to sleep. The sound keeps playing and your app sleeps (I guess - don't know this particular case).

Some things seemed really hard to do, but it is by design, and users really need to be protected from vampiric apps.

Re: Android vendors, don’t kill my app

#98
post #76

I dont get it? This is the best thing for me. Iam fed up of the notification loop of apps that I have to eventually delete. Thank god for telling me to buy a Nokia next time.

(assuming the claims on the site are correct, since I have no first-hand data on it) You really don't get that some people think apps like alarm clocks, sleep tracking, GPS logging, ... are useful and should be allowed to run if the user chooses them? To me , a phone that can't reliably run an application for a few hours is fairly useless.

I own a Nokia phone running Pie.

My alarms go off just fine (although I vaguely remember it not going off once or twice a few updates ago), my activity tracker works fine[0] and syncs periodically. I don't use GPS constantly. Signal notifications were also delayed a few updates ago, but now everything runs smoothly.

I find it a worthy sacrifice to make for a sturdy Android One phone with solid performance and a battery that can last two days on medium usage. My activity tracker lasts weeks without charging (comparable to a Kindle).

[0] Worth pointing out that my activity tracker was also developed by Nokia (before they've sold their health division to Withings), so it may receive some special treatment.

Re: Android vendors, don’t kill my app

#99
post #88
post #72

Earlier quoted context omitted.

Right, so 'open' Gentoo would get forked into a hundred locked down, obfuscated, proprietary flavours with all the same problems. In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.

> only a closed system with a single gatekeeper that can avoid this problem at scale I guess you are hinting at Apple phones but this works only because the gatekeeper is acting in good faith. Then again why do you need a single gatekeeper?

You clipped off my answer to that question from your quote.

I mean you can disagree, that's fine, in which case just say so.

Post reply on HN