The allow while in use approach for microphone/camera/location is less strict than the only while focused requirement for reading the requirement. It was done that way so that apps could still provide a user-facing feature via a visible notification without background access.
Conversation
Replying to
I think it should still explicitly say "allow while focused or showing activity notification" or something like that to make it clear to the user what they're supposedly consenting to.
1
Replying to
Since there's support for split screen and free form window management, it's more than just either focused or showing a visible notification. The unfocused app in split screen or unfocused apps visible on the screen for free form window management also count as foreground apps.
2
They should definitely include descriptions for these things somewhere. It's also unfortunate that the OS has a way to show the low-level permissions but doesn't explain them. Most are either part of high-level permissions, other toggles or only allow requesting access.
1
1
Replying to
That's what I mean. There's *no* user-facing documentation for this. Only developer-facing. I ran into all this moving from older LOS with PrivacyGuard (removed in 17 for Android's nerfed native thing) trying to figure out how to get stuff back.
1
Like most importantly, how to be able to use Maps when wanted without Google having a full-time location backdoor.
1
One nice big hammer I found in F-Droid repo is BackgroundRestrictor for all apps I just never want running when not focused. So stupid that this permission isn't in the standard Android perms UI.
1
Replying to
Android has a standard background restriction toggle in Android 12. It's in the Battery section of app settings where the default is Optimized and you can set it to Restricted which delays jobs, alarms, broadcasts, etc. until the app is manually started by the user.
1
1
The 3rd (non-default) Unrestricted mode replaces the prior battery restriction toggle. It's not presented as a privacy feature because it doesn't really make any strong guarantees. Another app can still call a service they export such as Play services delivering an FCM message.
2
1
So they can't simply run on their own in the background but they can get opportunities to run code in response to another app including Play services which happens all the time via FCM. Android 12's toggle does much more than all the prior third party attempts at it though.
1
Force stopping an app puts it into the STOPPED state which is also the state of a freshly installed app. It can still be launched by another app. A possible future improvement (could do it in GrapheneOS) would be making it so that only the launcher can start a force stopped app.
Replying to
Yeah, but that would require having another malicious app conspiring with the one blocked from background execution that's in foreground or not also blocked from background execution, no?
1
Replying to
Yeah, it would require an app conspiring. It's complex to enforce all the restrictions and they are gradually removing loopholes and making it stricter.
Apps are forced to use foreground services + ask for battery optimization exception to work around the stricter rules.
1
Show replies
Background restriction toggle isn't quite the same as force stopping but the result is fairly similar. It's definitely going to evolve further.
Android 10 through 12 introduced a bunch of restrictions on apps when they're running in the background. Gets much stricter over time.