Whenever I go to my homescreen or otherwise load another app the previous one closes. If I’m browsing Lemmy and I open a page linked on a post to read it, my app will have reset itself when I close the tab and I either have to give up or root around for the post.
This OS is borderline unusable in this state. It even evicts my homescreen app so there’s a 5-10 second lag when tapping the circle button.
Any tips? I have 8GB of RAM, which should be more than enough for a dozen apps.
Your phone is trying to keep your battery alive. The lower the specs of the phone, then the more aggressive the OS is. I don’t know how it works in Graphene but this is why many UIs now have and advertise multiapp ux like floating windows, split screen, floating icon and desktop modes. I suggest to use your phone intended keep app alive tactic.
I have a Pixel, I don’t have this problem, and I run it hard. Switch apps extensively, have ~250 user apps, rooted, numerous service apps (Foldersync, Syncthing, Resilio Sync, 2 versions of Telegram, Teleguard, 2 XMPP clients, VPN), etc, etc. The apps I want kept alive stay alive, the ones I don’t care about get hibernated when Android decides to.
OP is using Graphene, I’m using Lineage, both start from AOSP. There’s something overly aggressive in Graphene battery optimization config.
Your phone is trying to keep your battery alive. The lower the specs of the phone, then the more aggressive the OS is.
No, apps closing between switches is not a matter of battery, it’s a core feature of Android related to the management of RAM. Whenever the OS needs more available RAM, the OS will close a backgrounded app to make those resources available. This is why it happens more frequently on low-end devices - these generally ship with less RAM.
Some misguided vendors will limit background execution in incorrect ways in the name of saving battery, but the general thing with apps living in background is a story of RAM.
Interestingly enough, apps are supposed to be built to cope with being closed down due to lack of RAM and then be restored seamlessly, but this is an art that is uncommonly done correctly in the Android development space. The OS support is there, though.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
5. Engage respectfully: Harassment, flamebaiting, bad faith engagement, or agenda posting will result in your posts being removed. Excessive violations will result in temporary or permanent ban, depending on severity.
6. Memes are not allowed to be posts, but are allowed in the comments.
7. Posts from clickbait sources are heavily discouraged. Please de-clickbait titles if it needs to be submitted.
8. Submission statements of any length composed of your own thoughts inside the post text field are mandatory for any microblog posts, and are optional but recommended for article/image/video posts.
Your phone is trying to keep your battery alive. The lower the specs of the phone, then the more aggressive the OS is. I don’t know how it works in Graphene but this is why many UIs now have and advertise multiapp ux like floating windows, split screen, floating icon and desktop modes. I suggest to use your phone intended keep app alive tactic.
I have a Pixel, I don’t have this problem, and I run it hard. Switch apps extensively, have ~250 user apps, rooted, numerous service apps (Foldersync, Syncthing, Resilio Sync, 2 versions of Telegram, Teleguard, 2 XMPP clients, VPN), etc, etc. The apps I want kept alive stay alive, the ones I don’t care about get hibernated when Android decides to.
OP is using Graphene, I’m using Lineage, both start from AOSP. There’s something overly aggressive in Graphene battery optimization config.
No, apps closing between switches is not a matter of battery, it’s a core feature of Android related to the management of RAM. Whenever the OS needs more available RAM, the OS will close a backgrounded app to make those resources available. This is why it happens more frequently on low-end devices - these generally ship with less RAM.
Some misguided vendors will limit background execution in incorrect ways in the name of saving battery, but the general thing with apps living in background is a story of RAM.
Interestingly enough, apps are supposed to be built to cope with being closed down due to lack of RAM and then be restored seamlessly, but this is an art that is uncommonly done correctly in the Android development space. The OS support is there, though.
Activity Lifecycle.
That’s right. The art of correctly handling
savedInstanceStateis unfortunately not exactly well understood