7 ms·

Don't kill my app

59 points by tentacleuno 3y ago

tentacleuno 3y ago
Related: https://www.androidpolice.com/google-cts-d-app-killing/ https://www.androidpolice.com/google-cts-d-app-killing/
Torlan 3y ago
Don’t kill my battery
- fritzo 3y ago
  Yes, Dear app developers, different users want different things. 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.
  - ryandrake 3y ago
    Longer battery life is consistently number 1 on any survey of mobile phone users you'll find, ahead of camera. It's far and away what people care about. It's not surprising that phone manufacturers will do anything they can to improve theirs vs. competitions, including killing apps that are sitting there sucking up battery. 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-life-over-5g/ https://9to5mac.com/2021/03/19/iphone-buyers-want-battery-li... 2: https://www.gizchina.com/2023/05/08/do-you-have-mobile-phone-battery-anxiety-70-of-users-do/# https://www.gizchina.com/2023/05/08/do-you-have-mobile-phone... 3: https://www.businesstoday.in/technology/news/story/long-battery-life-fast-charging-in-smartphones-matter-most-for-consumers-263416-2020-07-08 https://www.businesstoday.in/technology/news/story/long-batt... 4: https://www.scmp.com/magazines/style/tech-design/article/2187248/its-longer-battery-life-we-want-most-our-smartphones-not https://www.scmp.com/magazines/style/tech-design/article/218...
    - izacus 3y ago
      Of course, those very same users then also want their chat messages and calls to actually work and work immediately. Their health data and step counters to sync. Their GPS trackers and location sharing to be SPOT ON and never lag behind the real world. Their music to keep playing and their chromecast controls to keep working. Their iCloud and Google Photos to sync if their phone gets stolen or dropped into a toilet. 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.
    - j16sdiz 3y ago
      Battery Life is something measurable. It shows well on tech spec and marketing materials. "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.
  - photonthug 3y ago
    So does GPS beacon then not qualify as an app? I guess here you can hope the vendor has an "official" beacon app that they grant battery-life exceptions for, but then you're screwed if you prefer a third-party beacon. Maps, those can be as safety-critical as a beacon too.. it would be a shame if someone cleared your map-cache because app-devs / mobile OS designers are optimizing for urban technophiles who have easy access to electricity. Or if that flashlight app breaks because it has an offline-mode that's insufficiently tested, and it chokes down when it's trying to load ads from an API it can no longer access! It's depressing to think about but bad UX, poor initial design, or just inevitable enshitification of perfectly fine working systems like this has no doubt actually killed people.
- jraby3 3y ago
  The best hack I’ve found for iOS (iOS isn’t even listed in the article) is keeping phone in low power mode.
  - toast0 3y ago
    iOS apps are built around Apple's policies which are more or less uniformly enforced on Apple phones. iOS apps started with near zero background compute and that was only added later. 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.
    - zahrc 3y ago
      > 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. 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.
- sebtron 3y ago
  Can't you close your apps when you don't want them to stay open? 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.
  - numpad0 3y ago
    Not sure what you meant by that - mobile apps don't have main() or exit(), they are driven by onThingsHappen(Event event) calls. When the OS decides to call `onYourAppIsResumedFromAltTab(context SwappedOutMemoryContent)` instead of `onYourAppWasJustLaunched(void)`, your app can resume functioning. The former is more likely to happen on devices with larger RAM space. You as an app developer don't have full control over it, unlike how it is(used to be!?) with Win32 apps.
    - sebtron 3y ago
      As a user, I can swipe up and hold from my home screen (depends on your launcher probably) and "swipe away" the apps I want to actually close, as in remove from the background. Not all of them comply, though.
  - deely3 3y ago
    Unfortunately it doesn't work like this. You can close the app, but app will wake up on any event - timer, call from server, any system event, etc. etc.
- deleted 3y ago
  [deleted]
arp242 3y ago
Previous: Android vendors, don’t kill my app - https://news.ycombinator.com/item?id=18901006 https://news.ycombinator.com/item?id=18901006 - Jan 2019 (407 comments) 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.
- buzer 3y ago
  > I'm not sure if it's been updated since then. There seems to some updates, https://dontkillmyapp.com/samsung https://dontkillmyapp.com/samsung shows update from 2021
- circularfoyers 3y ago
  Where did you bring this up? It would be interesting to read their response. If you hadn't, I imagine their Github repo would be the best place to do so https://github.com/urbandroid-team/dont-kill-my-app https://github.com/urbandroid-team/dont-kill-my-app
isodev 3y ago
It should be the opposite though? Don’t kill the battery, don’t degrade system performance, etc?
potyarkin 3y ago
Most apps on my phone were strong armed on me by trend-following (or outright data grabbing) businesses. 99% of them could've been just a website - but no, I can't reschedule my doctor appointment via website, because "our app is so much better and has so much more features!" So fuck yeah, kill them all! And if they dare to start on their own, kill them more!
- deleted 3y ago
  [deleted]
Noumenon72 3y ago
I've followed the Samsung instructions to try to keep it from killing SleepBot and Tasker, but I gave up and had to find workarounds instead. It should be easier to configure so you can make it not go to sleep for apps that set alarms or watch your other apps.
Racing0461 3y ago
Sometimes i hate apple for being a walled garden. Sometimes i love them. This is one of those times i like the vertical integration appl has that keeps quality high instead of going the OEM route goog/msft went. Now of course that can come back to haunt us.
Semaphor 3y ago
While nothing affects me personally (always been an AOSP user via Lineage/Cyanogen), I know that at least some apps struggle with vendor "enhancements" that go counter to what users want. DAVx5 (CalDAV/CardDAV sync) is one I remember having warnings about OnePlus (2nd worst here) during setup and how you need to take extra steps to ensure syncing actually works, which is pretty important for such an app. 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.
- kqr 3y ago
  I'm a happy user of DAVx5 and my employer just recently issued one of the more aggressive killing phones. 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.
  - Semaphor 3y ago
    It’s still opt-in in vanilla. But it’s a simple toggle.
    - kqr 3y ago
      That I did not know! It was a while since I used an AOSP-close ROM.
dreamcompiler 3y ago
I don't have much sympathy for this idea. The vast majority of apps don't need to do anything in the background, but almost every app thinks it's the only app on your phone and wants to be running and online 24/7 so it can constantly send you notifications, mine your personal info, and upsell you on crap you don't need. 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."
- sebtron 3y ago
  Many app need to keep state while they are in background though. Imagine your browswer tabs reloading every time you swotch to a different app and back.
  - pretext-1 3y ago
    Doesn’t mean your apps need to run in the background all the time. State restoration is a concept that has been present in Android/iOS from the beginning (or almost) and many apps implement it successfully. This is not why the “Don’t kill my app” author wants to run in the background. 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_controllers/preserving_your_app_s_ui_across_launches/ https://developer.apple.com/documentation/uikit/view_control... https://developer.android.com/topic/libraries/architecture/saving-states https://developer.android.com/topic/libraries/architecture/s...
    - sebtron 3y ago
      Yeah, but I was talking as a user. The worst case of this for me was with Google Maps, you'd think Google would know how to write apps for their OS.
sebtron 3y ago
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
shmde 3y ago
Battery on my phone is over 4 years old at this point. Please kill the app.
danmur 3y ago
I don't understand why Samsung is up there, at least on mine there's options to let it run things in the background when you need to. And otherwise, I'd rather not have apps hogging the battery in the background.
nneonneo 3y ago
One of the linked issues has this to say (https://issuetracker.google.com/issues/122098785 https://issuetracker.google.com/issues/122098785): > 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.
MzHN 3y ago
It's weird how this can be an issue in both directions. 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.
- SwiftyBug 3y ago
  Perhaps the OS recognizes those apps you use less as the ones that historically cause the least impact on battery, hence allowing them to run on background? If that is the case, this is pretty dumb.
kazinator 3y ago
How old is this? Under "other vendors" they are on about Android 6, 7 and 8. 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.
deleted 3y ago
[deleted]
WirelessGigabit 3y ago
Honestly, it's not just Android. iOS exhibits the same issue, and of-course Safari is exempt from this policy. 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.

59 points by tentacleuno 3y ago

Related: https://www.androidpolice.com/google-cts-d-app-killing/ https://www.androidpolice.com/google-cts-d-app-killing/

Torlan 3y ago

Don’t kill my battery

fritzo 3y ago
Yes, Dear app developers, different users want different things. 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.
- ryandrake 3y ago
  Longer battery life is consistently number 1 on any survey of mobile phone users you'll find, ahead of camera. It's far and away what people care about. It's not surprising that phone manufacturers will do anything they can to improve theirs vs. competitions, including killing apps that are sitting there sucking up battery. 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-life-over-5g/ https://9to5mac.com/2021/03/19/iphone-buyers-want-battery-li... 2: https://www.gizchina.com/2023/05/08/do-you-have-mobile-phone-battery-anxiety-70-of-users-do/# https://www.gizchina.com/2023/05/08/do-you-have-mobile-phone... 3: https://www.businesstoday.in/technology/news/story/long-battery-life-fast-charging-in-smartphones-matter-most-for-consumers-263416-2020-07-08 https://www.businesstoday.in/technology/news/story/long-batt... 4: https://www.scmp.com/magazines/style/tech-design/article/2187248/its-longer-battery-life-we-want-most-our-smartphones-not https://www.scmp.com/magazines/style/tech-design/article/218...
  - izacus 3y ago
    Of course, those very same users then also want their chat messages and calls to actually work and work immediately. Their health data and step counters to sync. Their GPS trackers and location sharing to be SPOT ON and never lag behind the real world. Their music to keep playing and their chromecast controls to keep working. Their iCloud and Google Photos to sync if their phone gets stolen or dropped into a toilet. 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.
  - j16sdiz 3y ago
    Battery Life is something measurable. It shows well on tech spec and marketing materials. "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.
- photonthug 3y ago
  So does GPS beacon then not qualify as an app? I guess here you can hope the vendor has an "official" beacon app that they grant battery-life exceptions for, but then you're screwed if you prefer a third-party beacon. Maps, those can be as safety-critical as a beacon too.. it would be a shame if someone cleared your map-cache because app-devs / mobile OS designers are optimizing for urban technophiles who have easy access to electricity. Or if that flashlight app breaks because it has an offline-mode that's insufficiently tested, and it chokes down when it's trying to load ads from an API it can no longer access! It's depressing to think about but bad UX, poor initial design, or just inevitable enshitification of perfectly fine working systems like this has no doubt actually killed people.
jraby3 3y ago
The best hack I’ve found for iOS (iOS isn’t even listed in the article) is keeping phone in low power mode.
- toast0 3y ago
  iOS apps are built around Apple's policies which are more or less uniformly enforced on Apple phones. iOS apps started with near zero background compute and that was only added later. 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.
  - zahrc 3y ago
    > 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. 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.
sebtron 3y ago
Can't you close your apps when you don't want them to stay open? 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.
- numpad0 3y ago
  Not sure what you meant by that - mobile apps don't have main() or exit(), they are driven by onThingsHappen(Event event) calls. When the OS decides to call `onYourAppIsResumedFromAltTab(context SwappedOutMemoryContent)` instead of `onYourAppWasJustLaunched(void)`, your app can resume functioning. The former is more likely to happen on devices with larger RAM space. You as an app developer don't have full control over it, unlike how it is(used to be!?) with Win32 apps.
  - sebtron 3y ago
    As a user, I can swipe up and hold from my home screen (depends on your launcher probably) and "swipe away" the apps I want to actually close, as in remove from the background. Not all of them comply, though.
- deely3 3y ago
  Unfortunately it doesn't work like this. You can close the app, but app will wake up on any event - timer, call from server, any system event, etc. etc.
deleted 3y ago
[deleted]

arp242 3y ago

Previous: Android vendors, don’t kill my app - https://news.ycombinator.com/item?id=18901006 https://news.ycombinator.com/item?id=18901006 - Jan 2019 (407 comments) 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.

buzer 3y ago
> I'm not sure if it's been updated since then. There seems to some updates, https://dontkillmyapp.com/samsung https://dontkillmyapp.com/samsung shows update from 2021
circularfoyers 3y ago
Where did you bring this up? It would be interesting to read their response. If you hadn't, I imagine their Github repo would be the best place to do so https://github.com/urbandroid-team/dont-kill-my-app https://github.com/urbandroid-team/dont-kill-my-app

isodev 3y ago

It should be the opposite though? Don’t kill the battery, don’t degrade system performance, etc?

potyarkin 3y ago

Most apps on my phone were strong armed on me by trend-following (or outright data grabbing) businesses. 99% of them could've been just a website - but no, I can't reschedule my doctor appointment via website, because "our app is so much better and has so much more features!" So fuck yeah, kill them all! And if they dare to start on their own, kill them more!

deleted 3y ago
[deleted]

Noumenon72 3y ago

I've followed the Samsung instructions to try to keep it from killing SleepBot and Tasker, but I gave up and had to find workarounds instead. It should be easier to configure so you can make it not go to sleep for apps that set alarms or watch your other apps.

Racing0461 3y ago

Sometimes i hate apple for being a walled garden. Sometimes i love them. This is one of those times i like the vertical integration appl has that keeps quality high instead of going the OEM route goog/msft went. Now of course that can come back to haunt us.

Semaphor 3y ago

While nothing affects me personally (always been an AOSP user via Lineage/Cyanogen), I know that at least some apps struggle with vendor "enhancements" that go counter to what users want. DAVx5 (CalDAV/CardDAV sync) is one I remember having warnings about OnePlus (2nd worst here) during setup and how you need to take extra steps to ensure syncing actually works, which is pretty important for such an app. 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.

kqr 3y ago
I'm a happy user of DAVx5 and my employer just recently issued one of the more aggressive killing phones. 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.
- Semaphor 3y ago
  It’s still opt-in in vanilla. But it’s a simple toggle.
  - kqr 3y ago
    That I did not know! It was a while since I used an AOSP-close ROM.

dreamcompiler 3y ago

I don't have much sympathy for this idea. The vast majority of apps don't need to do anything in the background, but almost every app thinks it's the only app on your phone and wants to be running and online 24/7 so it can constantly send you notifications, mine your personal info, and upsell you on crap you don't need. 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."

sebtron 3y ago
Many app need to keep state while they are in background though. Imagine your browswer tabs reloading every time you swotch to a different app and back.
- pretext-1 3y ago
  Doesn’t mean your apps need to run in the background all the time. State restoration is a concept that has been present in Android/iOS from the beginning (or almost) and many apps implement it successfully. This is not why the “Don’t kill my app” author wants to run in the background. 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_controllers/preserving_your_app_s_ui_across_launches/ https://developer.apple.com/documentation/uikit/view_control... https://developer.android.com/topic/libraries/architecture/saving-states https://developer.android.com/topic/libraries/architecture/s...
  - sebtron 3y ago
    Yeah, but I was talking as a user. The worst case of this for me was with Google Maps, you'd think Google would know how to write apps for their OS.

sebtron 3y ago

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

shmde 3y ago

Battery on my phone is over 4 years old at this point. Please kill the app.

danmur 3y ago

I don't understand why Samsung is up there, at least on mine there's options to let it run things in the background when you need to. And otherwise, I'd rather not have apps hogging the battery in the background.

nneonneo 3y ago

One of the linked issues has this to say (https://issuetracker.google.com/issues/122098785 https://issuetracker.google.com/issues/122098785): > 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.

MzHN 3y ago

It's weird how this can be an issue in both directions. 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.

SwiftyBug 3y ago
Perhaps the OS recognizes those apps you use less as the ones that historically cause the least impact on battery, hence allowing them to run on background? If that is the case, this is pretty dumb.

kazinator 3y ago

How old is this? Under "other vendors" they are on about Android 6, 7 and 8. 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.

deleted 3y ago

[deleted]

WirelessGigabit 3y ago

Honestly, it's not just Android. iOS exhibits the same issue, and of-course Safari is exempt from this policy. 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.