Ancestors

Toot

Written by Zack Weinberg on 2025-01-30 at 17:15

hey @GrapheneOS i would like to suggest an additional application containment feature:

some configurable number of hours after the user stopped interacting with an app, kill it and all its background processes, and do not allow it to run at all until the next time it is opened

i think this would make a nice complement to the existing "withdraw privileges from apps not used in a long time" mechanism

=> More informations about this toot | More toots from zwol@hackers.town

Descendants

Written by GrapheneOS on 2025-01-30 at 17:49

@zwol You can use the restricted battery mode to stop apps starting themselves in the background. Other apps can still start them unless you disable it.

=> More informations about this toot | More toots from GrapheneOS@grapheneos.social

Written by Zack Weinberg on 2025-01-30 at 17:59

@GrapheneOS I don't know where to find that in the settings screens?

=> More informations about this toot | More toots from zwol@hackers.town

Written by GrapheneOS on 2025-01-30 at 18:04

@zwol Per-app battery settings, change the default Optimized mode to Restricted to prevent the app starting itself in the background. It's not intended to be a privacy feature. Disabling the app is a different thing which outright prevents it running including preventing other apps starting it. Restricted battery mode will delay jobs, alarms, broadcasts etc. which would normally start the app until the next time another app starts it including you launching it from launcher, etc.

=> More informations about this toot | More toots from GrapheneOS@grapheneos.social

Written by Zack Weinberg on 2025-01-30 at 18:50

@GrapheneOS Hmm, my version of that screen is a little different (see attached). I presume that turning off "allow background usage" is equivalent to the "restricted mode" you mention.

But I don't think any of these modes are exactly what I want. What I want is to allow certain apps to run in the background for a limited time after they are used in the foreground. But after that time is up, they should be shut down and prevented from starting at all again, until reactivated by explicit user action (including share menus and the like, what I think are called "intents" internally, but not including any scenario where app A starts app B in the background without the user being aware that app B is somehow involved).

=> View attached media

=> More informations about this toot | More toots from zwol@hackers.town

Written by Zack Weinberg on 2025-01-30 at 18:54

@GrapheneOS Also I notice that disabling an app removes it from the launcher. That's not desirable in this case.

=> More informations about this toot | More toots from zwol@hackers.town

Written by GrapheneOS on 2025-01-31 at 01:55

@zwol That's because disabled launcher activities aren't shown. We could add an extra setting for this. It's not as simple as it seems since there are a bunch of things with disabled launcher activities that are part of the base OS you wouldn't want to have listed for no reason.

=> More informations about this toot | More toots from GrapheneOS@grapheneos.social

Written by Zack Weinberg on 2025-01-31 at 02:03

@GrapheneOS Er, let me clarify. It's fine for apps I explicitly disable to disappear from the launcher.* But this hypothetical no-background-activity-after-a-timeout mode, those apps should stay in the launcher and the share menu and so on, whether or not the timeout has expired.

• when some apps have been explicitly disabled, it might be nice to have a note at the bottom of the launcher "disabled apps not shown" and clicking on it brings up the settings page that lists all installed apps. but that's polish

=> More informations about this toot | More toots from zwol@hackers.town