Cranky again about how Android randomly reserves the right to kill applications for power management or its own inscrutable reasons, even if you have power management settings for the app set to "unrestricted".

So every time I open firefox it's a 50/50 shot whether my incognito tabs from my last browsing session (my default browsing mode to minimize leaving residue in history etc) are there or not.

On a desktop OS, apps randomly being terminated for no reason would be a sev1 issue. On mobile, it's just expected.

(is this something graphene or any of the other more user-respecting android forks / mobile platforms fix? When I launch an executable I want it to stay running until I tell it to stop, or it segfaults due to a bug, or I run out of ram or something. But barring exceptional circumstances it should run forever)
if the app says "I'm OK to kill and restart for PM" that's fine. but it should be a capability you advertise, that the OS doesn't try to use if you aren't able to handle it

@azonenberg if it were optional, people would not implement it, and battery lifetime would be in the toilet.

You can keep a background service running, but you need to display a notification that it's still there. Also, your app will not be killed while it's in the foreground and no screensaver is active.

@GyrosGeier "no screensaver is active" does that mean if i have the phone asleep and in my pocket or charging next to the bed with the screen off, it can still be killed?
@GyrosGeier As a user of Normal Computing Platforms (a la Debian) I expect to be able to put a device down, come back to it, and have everything I left open still there even if it's a year later as long as power wasn't lost
@GyrosGeier also firefox doesnt seem to implement incognito tabs as a background service?
@GyrosGeier what I want is to be able to browse without writing anything to persistent storage, but have those tabs remain open for weeks at a time potentially without going away

@azonenberg yes, "display off" means that apps can be killed. They usually aren't, because the app would be back in the foreground after unlock, but that's only true as long as no lock screen app is active (typically media player or navigation).

Usually apps are killed either to free memory or because they are inactive for several hours and the OS believes that disk caches are a better use of that memory, which is quite often true as the flash memory is encrypted, so reads are expensive.

@GyrosGeier sadly it seems like the mobile industry is infected by "the OS and apps are colluding to spy on you and monetize your data, while the OS tries just a little bit to keep the apps from spying on you so that you have to go through approved spying channels and pay the store tax etc".

Nobody trusts anybody, users still get datamined, and the APIs are handicapped which prevents plenty of legitimately useful things from being done.

I don't have a solution other than "an ecosystem based on free software and trust where users actually can have some level of assurance that applications are acting in their own best interests rather than serving some capitalistic ends"

@azonenberg the apps need to be distrusted — there is no real vetting process after all, so access rights are granted to apk signing keys, and apps signed with different keys are isolated from each other (apk signing keys are translated into uids).

A background service could hold ephemeral state (basically the browser would create an Intent like normal, serialise it and give it to the service for safekeeping instead of using the normal API, which saves the Intent to flash).

@azonenberg even with that, the page would need to be reloaded if the browser was killed, the Intents usually only keep the absolute minimum of state, and attaching the entire DOM tree would likely be too large. Background services are a lot more constrained in resident set size than foreground applications.