5 ms·

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

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.

matheusmoreira 3y ago
Why can't the app save its state to storage and restore the saved state when it's started again?
- kqr 3y ago
  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.
  - BoorishBears 3y ago
    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.
- happymellon 3y ago
  I was thinking the same. But I'm not an app developer so there is presumably a reason for that. Data exfiltration?
  - deleted 3y ago
    [deleted]
- masklinn 3y ago
  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.
  - deleted 3y ago
    [deleted]
  - resonious 3y ago
    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.
    - guappa 3y ago
      How to kill solid storage with one easy trick! Please don't do this.
      - resonious 3y ago
        How does it kill solid (state?) storage compared to writing JSON or SQLite constantly? Genuine ignorance on my part.
- numpad0 3y ago
  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.
- guappa 3y ago
  Because the developers are not skilled.
- g-b-r 3y ago
  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.
  - tsukikage 3y ago
    Hardly undocumented! https://developer.android.com/guide/components/activities/process-lifecycle 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.
    - g-b-r 3y ago
      The vendors-specific behaviors reported in dontkillmyapp are undocumented
osener 3y ago
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.
- erlendellingsen 3y ago
  Never experienced anything remotely similar as you described with either my iPhone X when I had that, or my current iPhone 12 Pro..
  - sooheon 3y ago
    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.
  - hot_gril 3y ago
    Even my iPhone 6S doesn't exhibit this behavior.
- kenferry 3y ago
  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.
- SwiftyBug 3y ago
  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.
ClassyJacket 3y ago
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.
- toast0 3y ago
  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)
  - kqr 3y ago
    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.
    - g-b-r 3y ago
      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.
      - kqr 3y ago
        Note that I was talking about writing processes to swap, not killing them!
        g-b-r 3y ago
        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
deleted 3y ago
[deleted]
Kwantuum 3y ago
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.
isodev 3y ago
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.
- g-b-r 3y ago
  These phones kill apps, not suspend them.
  - isodev 3y ago
    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.
    - g-b-r 3y ago
      Suspending means that its memory was preserved, so the app doesn't have to do anything !!!
      - isodev 3y ago
        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".
        g-b-r 3y ago
        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.
eviks 3y ago
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
guappa 3y ago
> 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.

matheusmoreira 3y ago

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

kqr 3y ago
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.
- BoorishBears 3y ago
  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.
happymellon 3y ago
I was thinking the same. But I'm not an app developer so there is presumably a reason for that. Data exfiltration?
- deleted 3y ago
  [deleted]
masklinn 3y ago
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.
- deleted 3y ago
  [deleted]
- resonious 3y ago
  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.
  - guappa 3y ago
    How to kill solid storage with one easy trick! Please don't do this.
    - resonious 3y ago
      How does it kill solid (state?) storage compared to writing JSON or SQLite constantly? Genuine ignorance on my part.
numpad0 3y ago
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.
guappa 3y ago
Because the developers are not skilled.
g-b-r 3y ago
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.
- tsukikage 3y ago
  Hardly undocumented! https://developer.android.com/guide/components/activities/process-lifecycle 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.
  - g-b-r 3y ago
    The vendors-specific behaviors reported in dontkillmyapp are undocumented

osener 3y ago

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.

erlendellingsen 3y ago
Never experienced anything remotely similar as you described with either my iPhone X when I had that, or my current iPhone 12 Pro..
- sooheon 3y ago
  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.
- hot_gril 3y ago
  Even my iPhone 6S doesn't exhibit this behavior.
kenferry 3y ago
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.
SwiftyBug 3y ago
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.

ClassyJacket 3y ago

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.

toast0 3y ago
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)
- kqr 3y ago
  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.
  - g-b-r 3y ago
    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.
    - kqr 3y ago
      Note that I was talking about writing processes to swap, not killing them!
      - g-b-r 3y ago
        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

deleted 3y ago

[deleted]

Kwantuum 3y ago

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.

isodev 3y ago

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.

g-b-r 3y ago
These phones kill apps, not suspend them.
- isodev 3y ago
  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.
  - g-b-r 3y ago
    Suspending means that its memory was preserved, so the app doesn't have to do anything !!!
    - isodev 3y ago
      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".
      - g-b-r 3y ago
        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.

eviks 3y ago

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

guappa 3y ago

> 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.