Don't kill my app
dontkillmyapp.com
dontkillmyapp.com
I'm not sure if it's been updated since then.
Still lists Sony as "toxic" for having an opt-in battery extension feature which warns you of the trade-offs (which I've found very useful when I really wanted to, well, extend battery life, e.g. when hiking or travelling). I told them this back in 2019, and that they got this so utterly wrong AND have failed to fix it leaves me rather distrustful of the entire page.
There seems to some updates, https://dontkillmyapp.com/samsung shows update from 2021
> As a company, we develop a library that collects sensor and location data from the device, sends it to our platform, and transforms it into meaningful information about the user (user habits, routines, etc.).
> Over the past years, it has been painfully difficult to support Chinese OEM devices (Huawei, Xiaomi, etc.). These OEMs are modifying Android in ways that break core functionality. The default behavior of these devices is to forbid newly installed apps to send/receive broadcasts, acquire wakelocks, start services, set alarms, etc. in certain conditions (e.g. screen off), unless the user explicitly whitelists the app.
Honestly, I would prefer such an app stay broken. I don't need the app collecting that data in the background. If the attitude of Android developers is that they should be permitted to run in the background and collect this kind of information without explicit background permission from the user, then it's a no-brainer for OEMs to push back in order to preserve battery life.
There are times when I don't want the OS to kill an app, and the OS can often fail in this aspect, causing loss of control.
However even more frustratingly, I've increasingly noticed that apps I only need rarely, maybe once a day, once a month, once a year, will still run in the background even with setting the app's battery settings in the OS to restricted.
There is _nothing_ I can do to stop them from running, except uninstall them, but that's a pain for apps I have no choice but to use, even if rarely.
This is a problem even on GrapheneOS which increases user control. You could temporarily disable apps, but it is such a tedious process that uninstalling might be easier.
The reason I first discovered "don't kill my app" is that my apps would close as soon as I switched to another one, in most cases. For example if I used maps and switched to a call / browser tab / Telegram chat, when I got back to the map the app would reload. My search would be gone, and I would have to set my destination again.
I hope you can agree that this is terrible user experience. If I wanted to save battery, I could have just closed my apps manually, I don't need my phone to take the initiative.
Ages ago apps used to have a bug where form contents were cleared if the user switched from portrait to landscape orientation -- same problem: developers assumed they could store state in instances of input fields, when in fact these would be re-instantiated when the view was significantly re-rendered.
This specific case seems like a continuation of that misunderstanding and a difference in intuition between Android architecture and PC developers, rather than an actual fault with Android.
Rotating your device or plugging in a keyboard should cause the UI to be torn down: it makes for a horrible UX and it's behavior that dates back to a phone that had 192MB of RAM.
It should have been ditched ages ago but in typical Android fashion lived on so long that now it can't really be changed and instead the SDK tries to work around it by providing developers with primitives to work around it.
But I'm not an app developer so there is presumably a reason for that. Data exfiltration?
They might also be lacking competence. My local bus authority’s application is barely able to keep track of its state while it’s running.
An other common situation is an applications getting in an irrecoverably broken running state. If the application preserves state on shutdown you might not be able to get it out of the broken state.
Please don't do this.
It won't be impossible to architect an app so that there would be an instance of a class that store all relevant states and load on creation, of course, and I'm guessing that level of competence is mid-six-figure quality in app world.
Most developers are not aware of them, and in any case it's very hard to constantly save all the state
Hardly any previous system in the history of computers has ever required it, and Android's developer documentation doesn't highlight enough how much it's required.
Most of all it's the fault of these phones' extreme, undeclared, undocumented and absurd behavior anyhow.
https://developer.android.com/guide/components/activities/pr...
The expectation in mobile environments is that you store whatever information you need to resume from cold in response to the app leaving the foreground, since the OS may kill it with little further warning at any time thereafter. This recommendation occurs prominently in the lifecycle docs for both iOS and Android.
And now I am experiencing similar issues, although not as severely yet, with my iPhone 12 Pro Max. Restarting the phone seems to help but there seems to be some battery and/or memory pressure that causes iOS to kill the non-active apps.
This drives me absolutely nuts.
Android and iPhones thought they'd look cooler if they didn't, resulting in a decade of endless frustration for many users.
I'm pretty sure that the task bar and start button could get swapped out btw, but they're quick to reload (except for the start menu and the tray icons)
But it’s weird and lazy that on an 8GB phone they kill the app rather than just suspend it (to stop it using any cpu)?
On iOS, even in low-power mode, and on a phone with far less RAM, apps rarely have to reload unless you’ve force-quit them or have gone for days without using them.
Hence my personal belief: GUI operating systems must evolve to slow down to match user-expected frequency of stimuli. Too fast and users leave, so they add crufts and weights until it's slow enough.
It is quite common for the OS to suspend apps when they're in the background or when the device is under low memory/power conditions. The fact that you as a user are experiencing it in the form of degraded functionality is a bug with the app itself and should be addressed by the developer.
As a reference, check iOS apps where the system monitors and controls each app's resource usage much more aggressively and a user is never aware of this.
So the map app is buggy… my expectation would be that it should be fixed.
Now of course that can come back to haunt us.
On vanilla, simply allowing permanent background or not seems like a great solution, I’ll allow it only where I really need it, and done.
I followed the steps suggested in the setup and it works just fine now. I'd much rather have a complicated opt-in to background activity than any form of opt-out.
This is why we can't have nice things. It's a tragedy of the commons where the commons is your battery and your data and your attention.
Phone manufacturers try to restrict this nonsense as they should, but the better solution is to give users complete control over background behavior, with the default being "none."
Also Android has ongoing notifications which let your app stay running forever and iOS introduced Live Activities in iOS 16 which can be used similarly (e.g. Instagram uses it to finish uploads in the background). But what the author of “Don’t kill my app” wants is to run in the background without making it obvious to the user, which many would consider malicious.
https://developer.apple.com/documentation/uikit/view_control...
https://developer.android.com/topic/libraries/architecture/s...
On Google Pixels, apps get aggressively killed in extreme battery saver mode. To spare an app from this, designate it as an essential app. No brainer.
When you're in Edge, switch apps, and go back, the amount of times Edge RELOADs the page is staggering. And of-course, reload means re-fetch from the server which isn't necessarily idempotent.
Yelp & HikingProject (REI): Same issue...
And given Apple's control over the ecosystem it's quite weird that tombstoning (what it was called on Windows Phone) isn't enforced, even though it's one of the most jarring experiences of using 'apps'.
And frankly, that would cover 99% of all battery life issues. The only reason these apps want to stay alive is to maintain state. State that can perfectly be serialized & restored.
So fuck yeah, kill them all! And if they dare to start on their own, kill them more!
The primary uses of my phone are (1) multi-factor authentication, and (2) as a GPS beacon whereby family can locate me if I'm injured in the wilderness. I definitely value battery life over app snazz.
Longer battery life was the clear winner with 73% of people picking it as the most enticing reason to buy a new smartphone.[1]
60% of surveyed mobile phone users stated they would switch phones if the battery life improved (China) [2]
61 per cent cited battery as the key consideration, just behind the smartphone camera (India) [3]
76 per cent of iPhone owners and 77 per cent of Android users listed longer battery life as something that will get them excited about buying a new phone (USA) [4]
1: https://9to5mac.com/2021/03/19/iphone-buyers-want-battery-li...
2: https://www.gizchina.com/2023/05/08/do-you-have-mobile-phone...
3: https://www.businesstoday.in/technology/news/story/long-batt...
4: https://www.scmp.com/magazines/style/tech-design/article/218...
But sure, it's the battery - it's just that the best way to save the battery (turn off the phone) isn't REALLY what's important ;)
And comments like yours are funny on this very site, because what this site complains is OEMs killing competition and choice by selecting apps that are allowed to be used - e.g. apps like Signal are the ones that suffer the most because they're not blessed by exceptions.
"Not killing apps", on the other hand, is hard to sell. User may notice some apps become less responsive, load slower, notification are delayed, etc.. but then they would blame the app, not the OS.
Don't get me wrong. I enjoy longer battery life.
OTOH, Android apps started with near zero restrictions on background compute and it's been added on in bits here and there. Two different Android phones may have drastically different policies and not because the user chose it. App developers can have difficulty making sure things work on phones where the manufacturer sets policies that limit when it can run or how it stays resident.
It's not always easy doing that for Apple, but there's not ten different ways you have to do things for ten different manufacturers.
Sure, there's tons of apps out there that have no business running in the background. But for every one of those, there's stuff that really needs it to work and the user wants it to work; the page on Samsung says some firmware versions would kill background execution if you hadn't used an app in 3 days, so if you had a weekly alarm in the clock app, and don't load the clock otherwise, it would likely not fire. That's not reasonable, and it's not what the user wanted or expected.
It's why, I, as a user, chose to stick with iOS. At least it's the devil I know, with the behaviour and boundaries that I can accept - without having to figure out every kink everytime there is an update.
I understand that some people prefer to tinker with their phones, I do not.
The reason I first discovered "don't kill my app" is that my apps would close as soon as I switched to another one, in most cases. For example if I used maps and switched to a call / browser tab / Telegram chat, when I got back to the map my search would be gone.
So no please, don't kill my app when I don't want you to.