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

231–240 of 414 posts

Re: Android vendors, don’t kill my app

#231

Post by noxToken »

aasasd wrote: post #204
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…

If Play Store allows to mark the app as incompatible with specific models, that might be the best recourse―since the app can't function properly on those phones anyway.

Isn't that basically a death knell - especially if you're not a top 10/50/100 app - when trying to reach customers? If you wait until the customer has downloaded your app, you'll probably have better retention. If you mark your app as incompatible, people won't even bother to install even though there could be a work around. You'd basically be trying to send a message to users about device manufacturers and the Android operating system while killing your own numbers.

Re: Android vendors, don’t kill my app

#233

Post by freehunter »

finchisko wrote: post #162
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…

>I understand why manufactures are doing this I really don't. User has power to uninstall or replace app that is in his opinion using too much power. There is no need for manufacturers to intervene. They should only display warning about app using too much power. But it seems killing app is so much easier for them.

The majority of people don't know how or even want to be an administrator on their phone. They'll just as quickly hand the phone off to someone else to fix it, or call support, or even just get a different new phone. It's way too much of a leap to assume most users will make the connection that their poor battery life is linked to an app misbehaving, then track down that app and uninstall it in favor of an app that is better on battery.

If Samsung kills the apps, the app maker gets a bad review. If Samsung doesn't kill the apps, Samsung gets a bad review. I know which one I would pick if I was Samsung. At that point it's up to the user to decide if that choice is something they want to subscribe to.

Re: Android vendors, don’t kill my app

#235

Post by sorenjan »

r3bl wrote: post #98
detaro wrote: post #76

Earlier quoted context omitted.

(assuming the claims on the site are correct, since I have no first-hand data on it) You really don't get that some people think apps like alarm clocks, sleep tracking, GPS logging, ... are useful and should be allowed to run if the user chooses them? To me , a phone that can't reliably run an application for a few hours is fairly useless.

I own a Nokia phone running Pie. My alarms go off just fine (although I vaguely remember it not going off once or twice a few updates ago), my activity tracker works fine[0] and syncs periodically. I don't use GPS constantly. Signal notifications were also delayed a few updates ago, but now everything runs smoothly. I find it a worthy sacrifice to make for a sturdy Android One phone with solid performance and a batte…

I read a comment on Reddit [0] from a Nokia user that had a large file transfer using Solid Explorer killed twice because he left the phone unattended and the screen shut off. It worked when he kept the screen on.

Would you mind testing if background file transfers work as standard and with manual battery optimization whitelisting?

[0] https://www.reddit.com/r/Nokia/comments/afkuh4/dontkillmyapp...

Re: Android vendors, don’t kill my app

#236

Post by rootusrootus »

anc84 wrote: post #193
CodeWriter23 wrote: post #127

Earlier quoted context omitted.

No, it’s the consequence of permitting background tasks at will. Apple took some heat, and there is learning curve associated with doing it their way, but they actually thought it through and created an energy-efficient architecture that addresses common use cases. And apps that don’t fit those use cases - what are they doing with your device?

Can I run XMPP or IRC on an iphone by now or does it still only receive messages when foregrounded?

I run Cisco Jabber on my iPhone, and it seems to run fine. AFAIK that is XMPP.

Re: Android vendors, don’t kill my app

#238

Post by finchisko »

freehunter wrote: post #233
finchisko wrote: post #162

Earlier quoted context omitted.

>I understand why manufactures are doing this I really don't. User has power to uninstall or replace app that is in his opinion using too much power. There is no need for manufacturers to intervene. They should only display warning about app using too much power. But it seems killing app is so much easier for them.

The majority of people don't know how or even want to be an administrator on their phone. They'll just as quickly hand the phone off to someone else to fix it, or call support, or even just get a different new phone. It's way too much of a leap to assume most users will make the connection that their poor battery life is linked to an app misbehaving, then track down that app and uninstall it in favor of an app that i…

>make the connection that their poor battery life is linked to an app misbehaving

that's why I mentioned, they could display some notification when app is using battery heavily (similar to ANR).

>The majority of people don't know how or even want to be an administrator on their phone.

Exactly same thinking as those device manufacturers. user = idiot (let's kill apps for him, what could go wrong, right?) This kind of thinking brought us here.

Re: Android vendors, don’t kill my app

#239

Post by Piskvorrr »

PunchTornado wrote: post #211
masklinn wrote: post #181

Earlier quoted context omitted.

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 applica…

been using android since forever. Now I'm on a s8+. I never had a case like this. maybe I didn't noticed it. But my alarm always went on like it should. my music always played. is this a bug that sometimes happens? how rare is it?

S8 has this, but can be opted out (plus it has what I assume is a whitelist of pre-approved apps, but even those can be opted in, IIRC). It's clumsy, but sort-of works. It does break some old apps that rely on scheduled wakeups, though :(

Re: Android vendors, don’t kill my app

#240

Post by bad_user »

alliecat wrote: post #206
bad_user wrote: post #192

Earlier quoted context omitted.

>> " 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 " iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does. _Example 1:_ fetch email (withou…

Background App Refresh has been a thing for ages - It took them a while, but Apple solved this problem in a super user-friendly manner.

No, they haven't solved it.
Post reply on HN