Launcher: display disabled apps in greyscale colors, add context menu

[secretmango]

Currently disabling Apps is a good feature (a workaround to prevent apps from automatically starting?)

But its UX is pretty bad, as they are "gone" once you disabled them.

Still displaying them in the launcher, and when pressing allowing to enable them again would be great.

more advanced, when longpressing an app allowing to disable if from there.

The UX could be similar to how work profile apps are still displayed and can be activated on press.

[thestinger]

Currently disabling Apps is a good feature (a workaround to prevent apps from automatically starting?)

Restricted battery might be want you want. Disabling them is to outright prevent them running instead of just heavily restricting when they can run to save power. They mostly can't start themselves with restricted battery mode, but other apps can still start them.

[secretmango]

thanks for the answer. So the init thing used in android cannot start them (or do apps control the init?) when they have restricted battery settings.

the first answer sounds interesting. Does GrapheneOS also add this AppOpsManager? It could stop Apps from receiving the BOOT_COMPLETED message so maybe they will not start.

In order to receive android.intent.action.BOOT_COMPLETED, apps need android.permission.RECEIVE_BOOT_COMPLETED which is a normal permission and hence can't be revoked by user.

So an option would be to remove this permission from the "normal permissions" and give it a manual opt-out switch?

Are there other factors determining if an app can start, for example other permissions? I imagine "SMS app" and "VPN App" would be there.

I think apps being invoked by other apps can be mitigated by the "app communication permission" that is in progress?

[thestinger]

The init process isn't involved with this kind of stuff at the application layer, it's system_server handling most of that. Android has a small init process with most of the complexity in system_server which would ideally be split up far more than they already did with Treble where the HAL functionality got split out into separate sandboxed processes.

Does GrapheneOS also add this AppOpsManager?

App Ops are an implementation detail of many of the permissions, special access toggles and battery restriction mode. Battery restriction mode does use those but it also does many other things.

So an option would be to remove this permission from the "normal permissions" and give it a manual opt-out switch?

Something being a normal permission doesn't mean there is no toggle, only that there is no standard permission toggle listed in permissions. Most of the special access permission toggles have low-level permissions corresponding to them which is why they aren't shown for every app. The battery restriction mode has multiple low-level permissions connected to it but implementing those things are separate toggles didn't make sense so that's why it's a Restricted vs. Optimized (default) vs. Unrestricted toggle for the overall ability to run in the background. Apps that are Restricted can still be started by other apps, like waking to receive push notifications from sandboxed Google Play via FCM.

[thestinger]

Trying to control how much an app can run or when an app can run based on the low-level permissions is incorrect. We don't do incorrect stuff like that.

I think apps being invoked by other apps can be mitigated by the "app communication permission" that is in progress?

Yes, but it doesn't change that battery restriction mode is the way to control how much apps can run in the background and toggling off App Ops is incorrect. That's only one part of how it works.

[secretmango]

okay thank you. So if I understood correctly, disabling apps to stop them from starting could be replaced by the some-time-to-come "app communication" permission + the restricted battery settings?

I am sure disabling an App does other things too.

So it doesnt matter, having an UI button for either "stop the app" (which is then greyed out, after setting battery to restricted, disabling "app communication" permission and stopping it) or "disable the app", which is also greyed out then, would be an UI improvement.

Clearing up ways to achieve that control is very important too, so thanks.

[thestinger]

Disabling the app outright prevents it running in any way. Restricted battery mode is for preventing the app running in background when not started by other apps including user starting it from the launcher.

[secretmango]

I found that apps can just lock "Battery optimized", mainly shitty Banking apps. You cannot change that then.

That means currently disabling is the only option, apart from Work profile / user profiles.

[thestinger]

Can you give an example?

[secretmango]

• Cambio Carsharing
• Elster secure
• GLS banking
• Securego plus (atruvia, partner of volksbank)
• ING Banking
• Comdirect
• Comdirect photoTan
• TK (german ensurance)
• FahrPlaner (german niedersachen train app)
• many more banking, identification and payment apps.

So basically all apps from Google Play I have...

[io43]

Yes battery optimized or even stopping the app don't totally prevent apps from starting under certain conditions, i noticed that too. When using shelter you can put shortcuts of disabled work profile apps to enable & launch them and there is a service to deactivate them again when the screen is locked it is really nice, something like that would be nice but that's just a though.

[secretmango]

Yes a UI exactly like the "enable" part of work profile apps would be fine. The "disable" part should be a context menu though, work profile apps need to be disabled all at once.

Also, the Work profile only works on the owner profile, just for your interest.