Live data from Hacker News

Android vendors, don’t kill my app

dontkillmyapp.com

211–220 of 414 posts

Re: Android vendors, don’t kill my app

#211
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…

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?

Re: Android vendors, don’t kill my app

#212
post #144

Earlier quoted context omitted.

On my phone (android), going to apps>selecting app I want to run in the background>battery>background usage I can allow the app to run unrestricted in the background. All android phones I've owned had this option.

My understanding from the OP website is that this is ineffective for certain popular phone vendors' customizations. In particular, the Nokia phone listed comes preinstalled with an app that aggressively shuts down any running process, whitelisted or not, if the screen has been off for 20 minutes. There's simply no way to stop this behavior apart from gaining root and uninstalling the battery "saving" app, or flashing…

A design so disrespectful it borders on malware.

Re: Android vendors, don’t kill my app

#213
post #71

Earlier quoted context omitted.

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 point is trash apps don't have to be a problem as long as the platform is managed properly. Anyway your trash app is probably someone else's fun entertainment.

I just doubt that "managed" platforms are delivering what they have promised and think that the quality of apps on more open systems is generally better by a few magnitudes without exaggerating too much.

And no, the trash app I am talking about exists to prey on unaware users by being an obvious fake or by extracting information about location, contacts and configuration.

"Managed" platforms accelerated this phenomenon in my opinion.

Re: Android vendors, don’t kill my app

#214

I don't understand why manufacturers are trying to solve problem for user. User has power uninstall app that is draining battery or replace it with something else. There is rating and comment section in app store exactly for this. What they could do instead is to display warning that app is using too much battery, but they SHOULD NEVER KILL AN APP. It may sound radical, but only countermeasure we developers have is t…

The user experience is more important than a app developer's need.

Users want better battery life. They don't want a app using it up.

Feel free to block the installation of your app on devices that you feel unfairly target background apps, they'll just use a different application.

Re: Android vendors, don’t kill my app

#215
post #170

Earlier quoted context omitted.

Would it be possible to detect that the app was killed while engaged in such a situration as yours, i.e. similar how to systemd detects killed apps with a keepalive ping written to the fs while engaged. Then on the next boot explain that you detected this, and guide the user to OP's page? Or is it way more complicated than so?

As TFA notes (in the Nokia section, possibly others): > This app kills apps in the most brutal way we have seen so far among Android vendors. You can't detect that your application was kill -9'd. I don't think you can detect that "PowerSavingAppG3" is running either (I'd guess it's running as root and you're not), so you can't even infer from its existence that your application will be traumatically killed in short o…

I think you are reversing what the parent comment meant. You can continually write to the sandboxed filesystem of your app, say write the current timestamp every 10 seconds, and a status of if the app exited gracefully (which you can control). Then when restarting the app you check if there was a timestamp written in the last say 2 hours and no graceful exit then you know the app was terminated and can explain that the app didn't crash but that the OS vendor force quit it.

Re: Android vendors, don’t kill my app

#216

If your app is in the background it shouldn't need a load of resources. These resource limits are there to prevent bad developers using all your resources in the background. If you are having issues with this limit you are probably one of these bad developers. Removing the limit is not the solution, writing a better app is.

So how do you propose to write a sleep tracking app that doesn't run a background process for longer than 20 minutes?

I have a Xiaomi and oneplus phone, neither of them have ever closed a background app so I dunno what you are talking about, but if phones are doing that then, yea fair enough thats a problem.

The wording in the linked website is talking more specifically about cpu limits, which is how most os manage background resources, whats the problem with that?

Sleep tracking is a good example you should use an event system, but developers are lazy and use "while (true) {}", which is my point.

Re: Android vendors, don’t kill my app

#217
I am glad that they are doing it. Also, I don't think this is being done for benchmarks or marketing. Pretty much all mobile manufacturers specify/market the battery capacity in mAh and not in terms of hours. Also, even in cases where the battery life is marketed as full day/2 day, I don't think it impacts the purchase decisions. Killing background apps has annoyed me sometimes, but there have always been solutions by tweaking the settings, in my experience (on Nokia, Xiaomi & Samsung). Overall, it has definitely improved my experience by drastically improving battery life. The article says "just to get a little more juice", which I have found to be untrue in my experience. For example, comparing the battery life of Xiaomi Redmi Note 3 running MIUI vs the same hardware running Lineage OS, the battery life was significantly better on MIUI and worth the sacrifice of spending some additional time in setting up apps for background execution. I wish my current Nokia phone was more aggressive in killing tasks.

Re: Android vendors, don’t kill my app

#218
On the other hand there is an uncontrollable mess of bad apps made even by reputable vendors such as Samsung that just sometimes enter whatever weird state that is impossible to debug and just drain battery like there is no tomorrow. More advanced power drainers don't drain battery themselves but hide in shadows and just keep the phone in "awake" state, essentially halving it's battery life and are very hard to catch and impossible to fix (except for uninstall). I'm both hands for ultra aggressive battery saving modes because if one or even ten apps malfunction it not good but acceptable, if in the evening of day 1 I have 5-10% of battery on the phone that is verifiable capable of running for 2 days, now this is unacceptable. It it renders Skype on mobile unusable, because it is always killed by battery saver, well to hell with such crappy app, their competitors work just fine in the same environment.

Re: Android vendors, don’t kill my app

#219
post #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…

You can set the notification to "Hide" in the App properties screen. You don't have to swipe it away/close it.

Re: Android vendors, don’t kill my app

#220

No mention at all about foreground services. That should fix all these issues.

Some manufacturers don't even respect the foregrounding of services! Our app's Service runs in the foreground, and is sometimes killed by the OS, e.g. on Huawei devices. This issue affects spotify too:

https://community.spotify.com/t5/Android/Music-stops-play-af...

Post reply on HN