Hacker News Reader

Comment by sebtron | Hacker News Reader

I think many commenters supporting the "kill my app" behavior do not understand how bad using the affected devices can be.

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.

View on HN

This somehow seems to have become an inevitable reality of mobile phones. I had to upgrade from my iPhone 7 because it had essentially become a “single-process OS” where even switching to Google Translate to help me compose a message would have the messaging app killed in the background.

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.

Never experienced anything remotely similar as you described with either my iPhone X when I had that, or my current iPhone 12 Pro..

Happened to me many times browsing restaurants / using a map during recent trip with 13 mini. Sucks to suffer a map reload when you're on roaming data with few bars.

Even my iPhone 6S doesn't exhibit this behavior.

iOS actually kills apps in the background FAR less than it used to. If your apps are not preserving state across being killed, it’s because they’re not doing the work to make sure the app death is transparent. Perhaps they’re more tempted to forego the work because it’s somewhat _less_ essential than it used to be.

I just replaced my iPhone 7 for the 13. I didn't notice a behaviour like what you described. Except for the Maps app while I had energy saver mode on.

Why can't the app save its state to storage and restore the saved state when it's started again?

I feel like this is how Android has been designed from the start.

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.

Nah configuration changes are definitely a fault.

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.

I was thinking the same.

But I'm not an app developer so there is presumably a reason for that. Data exfiltration?

Because it costs resources the developers are unwilling or unable to spend.

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.

I think Android dev is unnecessarily designed in a way that makes saving data require a lot of code. If you know what you're doing, you can mmap a file, put all your working memory in there, and let the OS save it for you. No serialization or parsing necessary and memory access is exactly the same as usual with no overhead. You'd think that using a managed language would make it easier to abstract and support this kind of thing but seems they'd rather require all app devs do manual saving and reloading of their app data.

How to kill solid storage with one easy trick!

Please don't do this.

How does it kill solid (state?) storage compared to writing JSON or SQLite constantly? Genuine ignorance on my part.

Because developers don't keep track of possible state changes that follows a callback? Mobile apps are not like C code with an entrypoint, you can't like dump all virtual memory to disk and write back to resume. It's all callbacks and object instantiations, and listing all objects is already a best-effort task.

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.

Because the developers are not skilled.

These phones go much farther the already absurd limitations of standard Android ("we know what apps a user doesn't care about so we'll kill them without asking, at any time").

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.

Hardly undocumented!

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.

The vendors-specific behaviors reported in dontkillmyapp are undocumented

I despise that this still happens today on a phone with 8GB of RAM. EIGHT GIGABYTES. That's what they sell the MacBook Pro with, but Android, built for low memory devices from the ground up, can't consistently keep a single application in memory in the background for just a few seconds. You can literally switch for five seconds and the last app has to reload.

This drives me absolutely nuts.

What's worse is when the task switching app and/or the home screen app have to be restarted. My phone only has 4 GB ram, cause it's nearly 3 years old and low cost, but still... I feel like windows 95 could run (poorly) on 4 MB and the start button and the task bar never swapped out. (Well explorer.exe did crash from time to time)

I have to admit I haven't fact-checked this on my own but I have it on fairly good authority that several versions of Windows could swap themselves out, sometimes resulting in a bluescreen.

Windows has ALWAYS asked the user which processes to kill under memory stress, except in the most extreme of conditions (when it crashed).

Android and iPhones thought they'd look cooler if they didn't, resulting in a decade of endless frustration for many users.

Note that I was talking about writing processes to swap, not killing them!

Yes indeed, I'm pretty sure that explorer.exe can or could get swapped out. I don't think that can result in a bdod though

The start button and the task bar are part of explorer.exe, although if I'm not mistaken the File Explorer windows have always been run in a separate instance of explorer.exe .

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)

I kind of understand manufacturers getting aggressive about rogue inefficient apps wasting cpu cycles and making their battery life look bad.

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.

8 GB of memory on a laptop is pathetic in 2023 and everybody knows it. And you're either using a very broken Android OS implementation or very unusual apps, it should not behave that way.

Yeah. It's supposed to be like 8 thousand UNIX computers. It just has to be insanely enormous bloat.

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.

You're describing bad app implementation.

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.

These phones kill apps, not suspend them.

From the app's point of view both are the same - the app can no longer execute code and upon resume it must restore state.

Suspending means that its memory was preserved, so the app doesn't have to do anything !!!

While suspending may be the first state, the OS can choose to fully evict the app from memory if it needs it for other tasks. So a "good app" saves state before being suspended so that upon resume, it can restore from disk even if it was "killed".

Yes, but in practice almost all apps don't do it always with the complete state,; and on phones that don't kill them so easily most of the times you can switch between apps without problems.

The most egregious problem caused by this that I've encountered is an almost complete inability to use email 2FA on websites because my phone will kill the browser as soon as I switch to my inbox, and when I go back to the browser I'm back on the login screen which will generate a new one-time-password and make the one I have in my clipboard worthless. I've also encountered the exact same problem with 2FA using an authenticator app, though since the codes are valid for ~30 seconds or so, if I manage to enter my credentials fast enough or they auto-fill, at least the code I copied is still valid.

That's indeed a terrible user experience, and the fact that the alternative isn't used (apps saving state even in trivial cases like which paragraph you're reading or a search query) adds to it. Wasting battery seems easier, so I'd also prefer to be able to configure to allow it rather than have all the apps killed and lose state, after all, it's my battery to waste

> I got back to the map the app would reload. My search would be gone, and I would have to set my destination again.

So the map app is buggy… my expectation would be that it should be fixed.

Reply on news.ycombinator.com