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.

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.

I was thinking the same.

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

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