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

311–320 of 414 posts

Re: Android vendors, don’t kill my app

#311

Post by yccheok »

I think Google should consider addressing this issue in their next Android.

If you browse through Alarm Clock app in Google Play Store, you will realize most them are having similar customer complain - "The app used to work till I upgrade Android OS"

Currently, I need to post the text in my Google Play Store description :-

" Reminder doesn't work reliably for certain devices. Their over aggressive Battery management mode, have prevent reminder to work in background. Please turn off that "feature", allow WeNote runs in background, if you want reminder to work reliably.

Please read https://dontkillmyapp.com/?3 for solution. "

Re: Android vendors, don’t kill my app

#312

Post by doubleunplussed »

scarface74 wrote: post #139
sudhirj wrote: post #77

Earlier quoted context omitted.

And yeah, the permissions model in Android vs Apple is different, but multi tasking in particular feels the same. i.e. Apple has fine grained permissions on demand for contacts, microphone, camera, location, etc, and requires that all apps gracefully degrade when permissions is denied. But for multitasking there isn’t really any fine grained permissions - as long as the app is doing a whitelisted task in the backgrou…

Technically, you could have an app that plays silent audio in the background to keep from getting killed and then do something else, but that would get flagged by the review process. But, if I recall correctly, VLC will continue a background file transfer session from its built in web server on iOS if you play a movie in the background. Otherwise it will be killed after 10 minutes.

I think they've wisened up to that trick. My girlfriend and I use a guided meditation app that has long silences in the audio. If the screen is off, her phone kills the app after about thirty seconds of silence, making the app practically useless.

I was going to report a bug to the app suggesting they include some ultrasonic or subsonic audio to defeat this mechanism, but it's just an arms race at that point. The phone will start looking at the total power in the audible spectrum to decide whether to kill the app or something.

This kind of thing is infuriating and prevents apps from doing anything outside of the box, stifling innovation and making users frustrated.

Re: Android vendors, don’t kill my app

#313

Post by trynewideas »

me551ah wrote: post #138
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…

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've had a Nokia 6.1 on Pie, apparently the worst-case scenario for this, for a few months. The third-party optimiser is running, and I haven't problems with Slack or Jabber clients. How are people reproducing this behaviour?

Re: Android vendors, don’t kill my app

#314

Post by Andrex »

apexalpha wrote: post #293
TruthSHIFT wrote: post #273

Earlier quoted context omitted.

From a usability perspective, this sounds crazy. Is is responsible of me to recommend Android to my non-technical friends?

I wouldn't say so. I got my grandma a cheap Android phone and a book to help her learn because I thought it'd be better since I also have Android and can help her. My grandma is 89 now, she uses Whatsapp, Youtube and whatnot and I am not kidding but within 2 months she had: - AVG antivirus (an ad told her she had a virus) - She had batterylife for 7 hours before a charge was needed due to shitty apps - Ads on her loc…

A cheap phone has worse functionality than an expensive* one? Forgive the snark but this comparison doesn't make sense to me.

*Speaking in terms of launch MSRP.

Re: Android vendors, don’t kill my app

#315

Post by Andrex »

njsubedi wrote: post #277
TruthSHIFT wrote: post #273

Earlier quoted context omitted.

From a usability perspective, this sounds crazy. Is is responsible of me to recommend Android to my non-technical friends?

No. For anyone non-technical I always recommend an iPhone. I can simply say, "Press this button if you need to open another app." The difference in UI/UX you see on different android phones and auto-hide enabled soft navigation buttons confuse non technical people a lot.

> No. For anyone non-technical I always recommend an iPhone. I can simply say, "Press this button if you need to open another app." The difference in UI/UX you see on different android phones and auto-hide enabled soft navigation buttons confuse non technical people a lot.

I wonder how they'll deal with the new gesture nav (both iOS and Android), because I think that's possibly more confusing to a layman.

Re: Android vendors, don’t kill my app

#316

Post by ecocentrik »

BoorishBears wrote: post #196
ecocentrik wrote: post #161

Earlier quoted context omitted.

If you're looking for user friendly ways to request privileges, that solution should really be offered by core android in a way that works for manufacturers and users and probably won't appease all developers. App permissions systems have been a nightmare for users from the start so you can't expect users to learn a newly revamped permissions system. They'll just continue to ignore permissions on install and complain…

What? The system you’re saying “evolved out of the manufacturers”, runtime permission requests, is from “core Android” all they way back at 6.0 And the problem has almost never been users blindly revoking permissions, it’s blindly granting permissions. The problem the parent comment mention isn’t the method of asking for permission, it’s the fact there literally is not a permission. And Android already has built in “…

> And the problem has almost never been users blindly revoking permissions, it’s blindly granting permissions.

If I wasn't clear, this is what I meant. Users ignore and accept permissions blindly on install.

> if Android did add a permission to allow an app to do whatever it wants

I'm not suggesting this at all. I'm suggesting that permissions systems, as granulated as they are, only make sense to developers and are mostly ignored by users.

> The problem the parent comment mention isn’t the method of asking for permission, it’s the fact there literally is not a permission.

I agree with the parent comment on this. Some permissions queries should be available on first use, rather than (or in addition to) on install.

Re: Android vendors, don’t kill my app

#318

Post by masklinn »

jessaustin wrote: post #247
dorfsmay wrote: post #228

Earlier quoted context omitted.

How do you differentiate an apps crash from an OS forceful kill? Both would show a last good status and no good exit.

You can detect which model of phone the app is running on, right? On these problematic models you should probably just assume that the app got killed in that circumstance.

Yes, but that's not a detection or even an inference, it's a loose assumption.

Re: Android vendors, don’t kill my app

#319

Post by sergiosgc »

TruthSHIFT wrote: post #273
sergiosgc wrote: post #271

I have an Android One Nokia (8 Sirocco), and: a) I wholeheartedly want this behaviour. The phone lasts 2-3 days without recharging, and I no longer fear leaving home with 30% battery. b) It's not an app that kills background apps. It's Android's own Background Activity Manager, where apps that are not whitelisted can't wake up the CPU. They run only when the CPU wakes up for some other reason (screen-on qualifies but…

From a usability perspective, this sounds crazy. Is is responsible of me to recommend Android to my non-technical friends?

It's not a usability problem. It's an option I'm very glad to have.

If you disable the background activity manager, under Settings | Battery, you get the same battery life you do on iOS (about a day, give or take).

Re: Android vendors, don’t kill my app

#320

Post by ascagnel_ »

morganvachon wrote: post #199
xyzal wrote: post #90

To be honest, as a user I really like the implementation of battery saving features of my Sony phone: 1. They are not enabled by default 2. Their settings screen explicitly states what the modes do 3. They can extend battery life significantly The most aggressive mode is called Ultra Stamina, and it works by basically turning the phone into dumbphone mode -- complete without any internet connectivity, calls, SMS and…

A much better (in my mind) solution to your backpacking battery life issue is to carry a phone with a removable battery. If you're turning off all services including calls and SMS, there's simply no reason for the device to be powered on at all, and removing the battery guarantees there's not even a trickle of power being drained. For your alarm, well I assume you wear a watch backpacking, so you can use its alarm fe…

> Of course, then you have the issue of finding a quality midrange or higher end phone with a removable battery in the first place. They are an endangered species due to the thinness war.

I prefer external charging bricks -- if you upgrade your phone, you might need to buy a new cable with an external brick, but you are more likely to need a replaceable battery with a new form factor or output.

Post reply on HN