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

181–190 of 414 posts

Re: Android vendors, don’t kill my app

#181

Post by masklinn »

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…

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

Hell there are comments in this thread testifying that these built-in "battery savers" even kill the built-in alarm application.

Re: Android vendors, don’t kill my app

#183

Post by kijin »

londons_explore wrote: post #101
kijin wrote: 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…

Yeah, I don't really expect a mobile O/S to keep connections open indefinitely. It's hard enough to do that when the phone is awake and on the move, much less sleeping.

The O/S should, however, honor an app's request to wake up every 5-15 minutes to open a new connection, do some things with it, and go back to sleep. Especially if the user has given explicit permission to let the app in question use all the battery it wants. Periodic wakeup is what most email apps expect when they're set to "polling" mode. It used to work perfectly until about two years ago. It doesn't work anymore on recent Samsung phones. The system just ignores the wakeup schedule set by the app.

Re: Android vendors, don’t kill my app

#184

Post by GeneralTspoon »

Nursie wrote: post #106
GeneralTspoon wrote: post #54

Earlier quoted context omitted.

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!

In that case you wouldn’t opt-in to beacon notifications.

But there are many people with varying use-cases - some of whome want reliable BLE detections on their devices. And if they opt-in to these notifications, then it’s a shitty experience when it doesn’t actually work as intended.

Re: Android vendors, don’t kill my app

#185

Post by scarface74 »

GeneralTspoon wrote: post #169
scarface74 wrote: post #145

Earlier quoted context omitted.

It makes Android overall seem more buggy (for example, not receiving notifications for an instant messaging app is pretty ridiculous, assuming I’ve opted in and want these notifications). Do instant messaging apps really need to be running to listen for notifications? Why isn’t listening for notifications being handled by one central Android process that then dispatches it and launches the app if necessary?

That’s exactly how it works - but this service itself is throttled. And, in Android 9, “App Buckets” will increase/decrease throttling depending on your usage of the app. For example, an app that you don’t open regularly, but do want receive timely notifications from (like a banking app, or calendar/scheduling app), might only get 1 window a day where it receives notifications.

There is a difference between a notification that is sent to the user just to tell them something and then the user can take action (meaning no need to wake up the app) and a notification to the app for the app to do something in the background.

The former should always get to the user, the latter on iOS is controlled by both the OS based on an algorithm and by the user who can specifically turn off background processing on a per app basis on iOS.

Re: Android vendors, don’t kill my app

#186

Post by kijin »

Nursie wrote: post #83
simias wrote: 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…

> 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? I don't think this is true in the later releases is it? I get a lot more ad-hoc permission requests these days, and there's much more control in the application settings (the android app settings, not the settings the app presents).

It is true to some extent since Marshmellow. But apps can tell when their permissions are denied, so some of them straight out refuse to start unless you give it all the permissions it wants. This is especially problematic when a new version of an app holds your data hostage and refuses to start unless you give it a ridiculous new permission.

The Play Store has no requirement that apps degrade gracefully when permissions are denied. So the result is usually the same as pre-Marshmellow. You just get more annoying popups.

I miss Cyanogenmod where I could deny a permission (e.g. contacts) and the app would have no idea it was denied (it would receive an empty list of contacts).

Re: Android vendors, don’t kill my app

#187

Post by me551ah »

eyko wrote: post #172
me551ah wrote: post #138

Earlier quoted context omitted.

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.

I have a OnePlus 6 and none of the apps you've just mentioned fail to receive notifications when my phone is asleep.

It does happen on oneplus devices and it's quite common to find complaints on oneplus forums like : https://bit.ly/2VSkhty . In all cases it is solved by adding these apps to the whitelist.

If you aren't facing issues then these apps are probably already a part of the whitelist on your device.

Re: Android vendors, don’t kill my app

#188

Post by [deleted] »

scarface74 wrote: post #143
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…

Does Android not have the concept of “local notifications” where you can tell the OS to schedule a notification to be sent to the app to wake it up instead of being in the background the whole time?

[deleted]

Re: Android vendors, don’t kill my app

#189

Post by Abishek_Muthian »

adrianhon wrote: post #148

For our Zombies, Run! run tracking/audio adventure app, "battery management" is turning into our most consistent customer complaint, to the point where it's impacting review scores, active users, and probably subscriptions. The result of the changes made by Huawei, OnePlus, Xiaomi, and Samsung mean that our app is killed during runs, and people interpret that as the app crashing. We're trying to figure out the best w…

Samsung is part of OHA (Open Handset Alliance) & Others have access to Google Play Services; so Google can in-fact ask them to stick to the android specs.

Background services management was let loose in Android till 6.0; with doze mode & Job scheduler it has vastly improved. I think manufacturers shouldn't start killing apps themselves, as shaming apps which abuse background services, eat power inconsistently by displaying notification & allowing user to 'force stop' the app themselves does the job as in OxygenOS.

For all the flak iOS gets regarding multitasking, I was impressed by their uncompromising attitude towards background services from the start, even when I was bashing my head during iOS development to implement features on par with android version. The background operations should be completed within 3 minutes, but there's no guarantee that it will not be killed before that!

Re: Android vendors, don’t kill my app

#190

Post by Abishek_Muthian »

traspler wrote: post #45

For me this problem is very real. For example I got my mother a Pocofone F1 (by Xiaomi). Everything works fine, WhatsApp notifications arrive but there are some apps which just get crushed by Xiaomi's battery saver. Audible's lock-screen widget for example just does not show up unless you enable/disable 2-3 battery saving and notification settings after installing the app. I think this incantation can't be expected e…

MIUI has always known for aggressive sleep patterns, considering Pocofone is an India targeted device & WhatsApp is the go-to social media platform in India; It's intriguing that they haven't fixed such issues.
Post reply on HN