Live data from Hacker News

Android vendors, don’t kill my app

dontkillmyapp.com

41–50 of 414 posts

Re: Android vendors, don’t kill my app

#41
I watch the evolution (and evolution is the right word here, given the complete lack of intelligent design) of Android APIs with a kind of morbid fascination; a ritual dance between inept API designers with the foresight of a two year old spotting an ice cream vendor across a busy street and app developers who (driven by management) have to buy into the fact that their life saving and community transforming app (CRUD app for ordering fast food or something like that) must support 34 kinds of real time notifications.

Re: Android vendors, don’t kill my app

#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 actually notify me at a reasonable interval (less than 10 minutes, if not immediately). Even after disabling every power-saving feature I could find, Samsung is still killing and crippling their own default app.

I understand that it takes a bit of battery to poll an IMAP server every few minutes. But if I want an app to be able to poll an IMAP server in the background at the cost of having to charge my phone a little more often, that's my choice. Besides, my old phone didn't have this problem and its battery still lasted a whole day.

What's even more infuriating is that the phone allows preinstalled social networking apps that I don't even use to continue running in the background while it happily kills the apps I actually need.

Re: Android vendors, don’t kill my app

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

Re: Android vendors, don’t kill my app

#44
post #4
post #2

The site lacks proper technical explanation of what the problem is exactly.

This sheds a bit more light on it, whilst still being non-technical: https://dontkillmyapp.com/problem/ It seems to be that these vendors ship builds of Android with aggressive battery-optimized defaults that breaks applications that rely on being able to run in the background.

Not just long-running background processes (e.g. gemerating a backup of your app). It may even prevent your push notification handler from running.

Re: Android vendors, don’t kill my app

#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 even from advanced users. Normal users will just give up and live with terrible UX, complain to the dev or switch to another app. The same goes for fitbit, getting it to sync in the background involves a similar mixture of battery saving and notification settings which are labeled in a way that noone would dare to change them or have questionable defaults. None of this was an issue on the Nexus 5X. To me it looks like Xiaomi has a whitelist of apps which get special defaults when installing so they work fine while others which are not on this whitelist don't get this treatment.

I can understand the benefits of aggressive battery saving especially as there are apps which behave badly but the state it has come to now is terrible UX and is just another frustration instead if actually delivering a benefit to the user. This seems to me like "optimisation" for the sake of benchmarks and marketing claims.

Re: Android vendors, don’t kill my app

#46

I haven't followed the scene closely, but isn't it the same behavior as Apple? Can you even do background tasks in iOS?

> I haven't followed the scene closely, but isn't it the same behavior as Apple? Can you even do background tasks in iOS?

This is about OEMs breaking the guarantees of the OS. Yes, Apple restricts your background processing time, but it will still reliably deliver APNS push notifications or keep your running if it's actively providing turn-by-turn nav, background calls or something that API deliberately allows you to do.

With Android, the issue is that OEMs listed on that site break guarantees that Android API gives you. Your app suddently stops receiveing push notifications because it's not on the whitelisted "golden set" - breaking smaller messengers like Signal. Or the OEM "battery saver" kills off Google Maps while it's running turn-by-turn during your drive. Issues like that, which are significantly different than having Doze mode save your battery. Or you schedule a sync job once per day on Wifi (which JobScheduler API gives you the ability to do) and Huawei decides to just break the API and not run it.

Re: Android vendors, don’t kill my app

#47

I haven't followed the scene closely, but isn't it the same behavior as Apple? Can you even do background tasks in iOS?

As a developer, you are aware of the limitations so that you can work with them. E.g. when your app is closing down you have X ms to wrap your work up. But you can also request a longer task, or request the app to work in the background in certain scenarios. And as there is only 'one iOS', it will always work as 'agreed on'. It seems like in Android the developer just assumes their app will be able to run in the back…

> It seems like in Android the developer just assumes their app will be able to run in the background, except some versions just decides to kill it based on their own agendas.

That hasn't been true for some versions now. Yes, there's a mode where apps can run in the background without restrictions, but that hasn't been true for most apps for years now.

Re: Android vendors, don’t kill my app

#48

tl;dr The author would like to run his app in the background without notifying the user about it, because otherwise the author would just add add an ongoing notification, which would allow the app to run in the background forever on all platforms.

If this were the solution, I'd have to have a notification that I can't swipe away for email, Telegram, Wire, navigation while navigating, music player while playing, alarm clock when an alarm is set... So say I'm driving with music, that's five useless notifications. The app can ask me on first launch if I want it to do this or not, rather than being permanently in my face about it.

The notification area is becoming increasingly useless (for actual notifications). Since upgrading from 4.4 to 7.0 last year, this has been bugging me quite a bit and I haven't yet found a solution. I was much happier with the old OS, but security updates...

Re: Android vendors, don’t kill my app

#49
post #15

I haven't followed the scene closely, but isn't it the same behavior as Apple? Can you even do background tasks in iOS?

In iOS, you have a few narrow cases where you're allowed to run in the background; some of which are specified to only maybe run. In Android, you're technically allowed to run whenever you feel like it, but starting with Android 6, Google started limits, but I don't think apps get much feedback about when they might run, or if they can access the network when they do run. And the multitude of OEMs that are all dieing…

> I understand the intent of these features, but there really needs to be a better way. Some apps do real, useful, work in the background, and it's not great for users when that can't happen. Many apps should probably only run when they're in the foreground. Either way, the app should be informed, so it can do the best it can, including informing users why it's not working and being able to direct users to where they can fix it, if desired.

This is why Android allows you to still run unrestricted if you show a persistent notification (as long as there's enough RAM). The whole point of the link you're commenting on is that some OEMs break this API.

Re: Android vendors, don’t kill my app

#50

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.

I think it's a delay loading the images - it's scored by poo emojis.

It took a few seconds for that to be visible when I visited the page, initially only showing as large dots.

Post reply on HN