Live data from Hacker News

Android vendors, don’t kill my app

dontkillmyapp.com

101–110 of 414 posts

Re: Android vendors, don’t kill my app

#101
post #42

The default mail app on my recent-ish Samsung flagship phone notifies me of new email anywhere from 30 minutes to 1 hour late. I used to depend on K9 Mail for business on the go, but it was even worse: notifications were often several hours late. Android was dropping the IMAP connection and not allowing the app to reconnect for a routine poll. There doesn't seem to be any general-purpose email app on Android that can…

The social media apps will almost certainly use Googles push notification service, which is the only background notification allowed.

Your imap client is trying to hold a TCP connection open to your server, which isn't allowed.

There's a good reason the phone doesn't allow that. Firstly, the push notification service can be waiting for a notification for an app while the app is entirely unloaded from RAM. Hundreds of apps can be listening for notifications at once, with no system resource overhead.

Secondly, imagine every app wanted to have a TCP connection open to it's own server. TCP must generally go through your wifi/3g providers NAT. That NAT gateway will drop idle connections, with the rules on which connections are dropped varying for every type of router and provider. In general, if you want reliable delivery, you're going to have to send some packet down a TCP connection every 5 minutes, although some providers it can be up to every 3 hours. If every app applies it's own heuristics to figure out how often to send a keep-alive message, and you have hundreds of listening apps each with their own connection, and no synchronisation between them, your phone will end up waking up every few seconds for some app to send a keep-alive.

Instead, Google keeps open just one connection. They have a serverside database of all network providers to know which ones drop connections when (BTW, this is a big advantage of using your cable providers default modem. If you have your own modem, this mechanism won't be accurate). It can then wake up and send just one keep-alive at the exact correct time.

From the server side, Google can batch messages to clients. It can decide that receiving 8 new marketing emails is important enough to sync to your phone, but only if the phone will be waking up for some other reason. Then when a snapchat message comes in, both the mail app and snapchat will be notified by a single wakeup of the phone.

Overall, it's a very good design. There are only 2 big downsides:

1) It's centralized. Nobody else can run a notification server. They have a monopoly on delivering notifications.

2) Their server isn't very good. It doesn't have the capability for example to simultaneously listen on 3G and wifi. It sometimes gets overloaded and unnecessarily delays messages. Their database of network providers is sometimes a bit off, meaning your phone is sending keep-alives every 30 minutes, while the connection times out after 20 minutes, meaning there is a 33% chance your message will get delayed by up to 10 mins.

Re: Android vendors, don’t kill my app

#102

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…

Ehm, no?! I want more control over what runs not less. It's my electricity on my phone, I certainly don't need someone else auctioning it off like my phone is a billboard.

Your idea basically means that apps that spam ads can use more power, even if they're used less. And free or paid apps without ads couldn't afford to run at all. How does this help the user?

Re: Android vendors, don’t kill my app

#103
Here's a process management UX I've been asking for ever since Android came out:

I want to have a list of all running apps and their background services. I want to be able to put any app/service from this list down, and have it stay down. That is, I want the ability to kill an app and/or their services, and not see them again until next reboot or the next time I launch the app in question.

It's not that big of an UX burden, and it would solve a lot of the battery management issues.

Re: Android vendors, don’t kill my app

#104
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…

>I don’t think you could implement a tracking socket masquerading as a background download

The Facebook app used to play a silent audio track to stay active in the background, until they got called out: https://www.reddit.com/r/iphone/comments/3opxhm/facebook_app...

Re: Android vendors, don’t kill my app

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

The right way to solve this is with explicit permissions (similar to iOS). Rather than arbitrarily and sporadically crippling apps with opaque limitations. Google & manufacturerers have gone too far in the quest for the Holy Grail of extending battery life. To the point where it’s negatively affects the user experience quite often (there are quite a few examples in these comments). It makes Android overall seem more…

God save us from beacon-related functionality anyway. No I don't want my day interrupted for a message about your service, sorry!

Re: Android vendors, don’t kill my app

#107
post #105

Is this why the alarm never went off reliably on my Android phone? (iOS user now)

It might be. I never had an issue with this on my previous OnePlus phone (which at least at the time was pretty close to stock Android), but I was stumped to see that the Google Clock alarm was not going off multiple nights (seemingly at random) on my new Huawei phone. Turns out the phone was closing the app in the background due to it running for a long time... huh.

Switching the the built-in clock app (it's whitelisted, probably) fixed the issue, though it's not a good user experience. (To note: there is a settings screen to override per-app background closing behavior, but for an alarm clock I don't mind so much which app I end up using.)

It is pretty annoying still having the whitelist e.g. VPN apps manually whilst travelling as the phone was closing them constantly.

Re: Android vendors, don’t kill my app

#108
post #77

Earlier quoted context omitted.

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…

>I don’t think you could implement a tracking socket masquerading as a background download The Facebook app used to play a silent audio track to stay active in the background, until they got called out: https://www.reddit.com/r/iphone/comments/3opxhm/facebook_app...

Holy crap, I didn’t know that. Yet another reason I was right to uninstall the app and just use the website.

Re: Android vendors, don’t kill my app

#109
post #8

Custom alarm clocks and health trackers work fine on my OnePlus. What is the problem exactly?

I had problems with synchronization between my OnePlus 3 and my Fitbit tracker (it'd work fine for an hour or a day and then just stop), but those problems went away when I upgraded to a OnePlus 6T. Regarding slack notifications and similar things, all I can say is that they sometimes appear a few seconds later than on my active desktop, but I don't find that delay to be a problem.

I had problems with my FitBit and other Bluetooth devices on my OP3 running stock firmware but these have all been resolved since I moved to LineageOS. Battery life seems better too (although I haven't explicitly measured).

Re: Android vendors, don’t kill my app

#110
post #105

Is this why the alarm never went off reliably on my Android phone? (iOS user now)

It might be. I never had an issue with this on my previous OnePlus phone (which at least at the time was pretty close to stock Android), but I was stumped to see that the Google Clock alarm was not going off multiple nights (seemingly at random) on my new Huawei phone. Turns out the phone was closing the app in the background due to it running for a long time... huh. Switching the the built-in clock app (it's whiteli…

Interesting. Mine was a Motorola handset. I gave up with Android in the end due to stuff like this. I don't want to have to fight the tech I use to keep it doing what I want it to do.
Post reply on HN