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

61–70 of 414 posts

Re: Android vendors, don’t kill my app

#61

Post by me551ah »

GeneralTspoon wrote: post #57
me551ah wrote: 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.

What we observed was that in cases of devices like xiaomi and oneplus, the app goes into a state of being force killed. So even if the notification sent is one without a data payload ( in which case the app is not woken up ) , the notification will not be displayed to the user. To get around this issue we sent all messages with a data payload to ensure that the app is woken up(or atleast the system tries to wake it up).

Re: Android vendors, don’t kill my app

#62

Post by raxxorrax »

sudhirj wrote: post #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 servi…

I think the locked environments we have on phones is the reason we see a lot of trash apps. You don't have this development on more open platforms. At least no to that degree. So both, Apple and Google are at fault here.

It is not the API, it is not threading capabilities. Just shitty and locked environments. So define as many additional rules as you like. Won't change much.

Re: Android vendors, don’t kill my app

#63

Post by perlgeek »

https://dontkillmyapp.com/samsung

> Yes, even Samsung - a dominant vendor in the Android market - is using nasty battery saving technique which may kill background processes and render alarm clocks useless. See below for workarounds.

Wait, do you really need a background task for alarms?

(why) isn't there a system-level service to notify and wake up your app at a pre-defined time or interval?

Re: Android vendors, don’t kill my app

#64

Post by tass »

raxxorrax wrote: post #62
sudhirj wrote: post #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 servi…

I think the locked environments we have on phones is the reason we see a lot of trash apps. You don't have this development on more open platforms. At least no to that degree. So both, Apple and Google are at fault here. It is not the API, it is not threading capabilities. Just shitty and locked environments. So define as many additional rules as you like. Won't change much.

What is a trash app by your definition?

Re: Android vendors, don’t kill my app

#65

Post by expomarker »

perlgeek wrote: post #63

https://dontkillmyapp.com/samsung > Yes, even Samsung - a dominant vendor in the Android market - is using nasty battery saving technique which may kill background processes and render alarm clocks useless. See below for workarounds. Wait, do you really need a background task for alarms? (why) isn't there a system-level service to notify and wake up your app at a pre-defined time or interval?

> (why) isn't there a system-level service to notify and wake up your app at a pre-defined time or interval?

there is. But, defining services is extremely easy and so people often just roll their own. Plus, it's academic.

Re: Android vendors, don’t kill my app

#66

Post by seszett »

perlgeek wrote: post #63

https://dontkillmyapp.com/samsung > Yes, even Samsung - a dominant vendor in the Android market - is using nasty battery saving technique which may kill background processes and render alarm clocks useless. See below for workarounds. Wait, do you really need a background task for alarms? (why) isn't there a system-level service to notify and wake up your app at a pre-defined time or interval?

No, you don't need a background task for alarms. There is a JobScheduler API for that.

The aggressive battery settings of most vendors only interfere with badly coded apps to begin with, apps that use background tasks when they should be using more appropriate APIs.

Re: Android vendors, don’t kill my app

#67

Post by dtech »

daveFNbuck wrote: post #20
me551ah wrote: 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 Slack or Gmail to deliver notifications instantly. I'd love to have functionality that saves battery by delaying them.

So why not disable the notification functionality if you don't want it?

Re: Android vendors, don’t kill my app

#68

Post by mcv »

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…

I got weirder behaviour from the stock Android email app: I discovered it's sending emails weeks late. When I discovered this, I found one email that was several months old lingering in my outbox.

Probably not related to this, but still incredibly weird, not to mention seriously broken.

Re: Android vendors, don’t kill my app

#69

Post by gadders »

perlgeek wrote: post #63

https://dontkillmyapp.com/samsung > Yes, even Samsung - a dominant vendor in the Android market - is using nasty battery saving technique which may kill background processes and render alarm clocks useless. See below for workarounds. Wait, do you really need a background task for alarms? (why) isn't there a system-level service to notify and wake up your app at a pre-defined time or interval?

My Galaxy S6 was really aggressive for closing apps that it thought might impact battery life. Specifically, it was always closing one app I used to record my workouts in the gym. Very annoying.

My S8 seems a lot less extreme in this regard.

Re: Android vendors, don’t kill my app

#70

Post by squarefoot »

raxxorrax wrote: post #62
sudhirj wrote: post #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 servi…

I think the locked environments we have on phones is the reason we see a lot of trash apps. You don't have this development on more open platforms. At least no to that degree. So both, Apple and Google are at fault here. It is not the API, it is not threading capabilities. Just shitty and locked environments. So define as many additional rules as you like. Won't change much.

The locked environment may prevent users from removing branded crapware installed by vendors, but it's not its cause. Popularity is. If Gentoo Linux (just to name one we wouldn't expect Joe User to know) became popular as Android on cellphones, we would see in no time vendors trying to cram their crapware into every platform running Gentoo as well, but its open nature would allow users to remove unwanted stuff, so vendors would use any tactic to make it less open in order to force users to run their crap, get more brand exposition, steal personal data etc.
Post reply on HN