Live data from Hacker News

Android vendors, don’t kill my app

dontkillmyapp.com

51–60 of 414 posts

Re: Android vendors, don’t kill my app

#51

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.

Something on your end is not loading (JavaScript off?)

Each vendor has 1-5 poop emojis with Nokia having 5 and Stock Android only 1

Re: Android vendors, don’t kill my app

#52

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.

Your TL;DR is wrong and it completely misses the core issue the website is describing. It's about OEMs breaking core Android API guarantees in cases where the OS (by documentation) allows you to run in the background for short bursts during so-called Doze maintenance interval.

Re: Android vendors, don’t kill my app

#53
post #24
post #7

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 don't want WhatsApp (owned by Facebook) to run in the background on my phone at all times. I don't trust them, especially after Instagram (also owned by Facebook) started using the camera by itself on my phone, without my permission. Slack would be fine, I guess.

Then you need to uninstall the app. No phone is going to guarantee you that it won't run.

Re: Android vendors, don’t kill my app

#54
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 buggy (for example, not receiving notifications for an instant messaging app is pretty ridiculous, assuming I’ve opted in and want these notifications).

One other big issue is that push-based wake-ups on Android don’t work reliably. For example, on iOS, if you want to wake up the app in the background when you come in range of an iBeacon, you can do so (with user permission), and it just works. Meaning you don’t need to run a special arbitrary background job (which is much less battery efficient).

On Android - BLE wakeups are so incredibly unreliable that entire classes of apps are becoming less and less viable. And without the loophole of running background jobs to manually scan for beacons, users (and developers) are basically shit out of luck.

Re: Android vendors, don’t kill my app

#55

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

You don’t need to, most of the time.

For example, push notifications are handled by one system process, and will only open the relevant app when the user clicks it.

Re: Android vendors, don’t kill my app

#56

Earlier quoted context omitted.

I don't want Slack or Gmail to deliver notifications instantly. I'd love to have functionality that saves battery by delaying them.

Both these apps allow you to do that in-app. I have Gmail not notify me for work emails and notify me for stuff on my personal account.

That doesn't save the battery though.

Re: Android vendors, don’t kill my app

#57
post #5

Interestingly though it is possible to remotely detect which users are facing this problem and send them instructions on how to add an app to the device's whitelist. I faced this exact problem in my previous company Flock, and built services to detect and inform users which substantially brought down user complaints. https://hackernoon.com/notifications-in-android-are-horribly...

Nice write-up, and interesting idea.

But how did you guys deal with the situation where FCM delivers and displays a notification without waking your app up. In that case, if the user dismisses the notification without opening it, then it will count as delivered by FCM, but not as delivered by your app, right? Which isn’t actually the case.

Re: Android vendors, don’t kill my app

#58
This is the Android multitasking lead finally coming fully circle. Android had multi tasking much earlier and in a more powerful way by allowing apps to start their own serivices and do pretty much whatever they wanted, but this is the unfortunate logical result - apps that agressively kill other apps, installed by the handset manufacturers, to protect users from badly written apps that drain the battery in the services.

Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks (audio playback, downloads, alarms, notifications) to the OS, and made clear guarantees about the circumstances under which the APIs would work.

Post reply on HN