3 ms·

This is what kinda bugs me about Android permissions - they're very binary. Either an app has location permissions or it doesn't. Personally, I would love to be

This is what kinda bugs me about Android permissions - they're very binary. Either an app has location permissions or it doesn't. Personally, I would love to be able to say "Google Maps has access to location info while it's in the foreground, but not while in the background." For that matter, it'd be nice if I could stop certain apps from running in the background at all. A task killer isn't the answer here - a few seconds is enough to gather some data and transmit it, and at that point the damage is done.

xg15 10y ago
On Android there is not actually a meaningful concept of an app "running" vs "not running". Each app is actually a collection of components that are registered to different system hooks ("intents"). Whenever such a hook is triggered, the OS launches the components of all apps that registered for that hook. What would be interesting IMO were some way to see which app has registered which intents and possibly an option to override those registrations.
- johnm1019 10y ago
  I'm not convinced it would be so hard. I imagine something like ForegroundToken's: Activities (now plural with multi-window) in the foreground (onResume) gain access to a ForegroundToken. The service requests require you to pass in the ForegroundToken. This token is then validated at the moment of the request. When the app goes into the background the system invalidates the token, so any work waiting in queue somewhere will actually fail on the token check when it comes up. If you want to ask a background service (of your own), or fire off an intent, you pass the ForegroundToken with it. If the work starts while your app is still in the foreground peachy, if not, it fails. In a foreground > background > foreground cycle, your app gets a new ForegroundToken on every onResume event. If you want apps to have true background access to a permission, that is a separate toggle (yes more complicated I know, but theoretically possible). They then can pass null into the ForegroundToken argument.
kilotaras 10y ago
If you're rooted xposed with xprivacy has 1. More finegrained permissions (per api call basically) 2. Ability to give/deny permission per use case or some time.

xg15 10y ago

On Android there is not actually a meaningful concept of an app "running" vs "not running". Each app is actually a collection of components that are registered to different system hooks ("intents"). Whenever such a hook is triggered, the OS launches the components of all apps that registered for that hook. What would be interesting IMO were some way to see which app has registered which intents and possibly an option to override those registrations.

johnm1019 10y ago
I'm not convinced it would be so hard. I imagine something like ForegroundToken's: Activities (now plural with multi-window) in the foreground (onResume) gain access to a ForegroundToken. The service requests require you to pass in the ForegroundToken. This token is then validated at the moment of the request. When the app goes into the background the system invalidates the token, so any work waiting in queue somewhere will actually fail on the token check when it comes up. If you want to ask a background service (of your own), or fire off an intent, you pass the ForegroundToken with it. If the work starts while your app is still in the foreground peachy, if not, it fails. In a foreground > background > foreground cycle, your app gets a new ForegroundToken on every onResume event. If you want apps to have true background access to a permission, that is a separate toggle (yes more complicated I know, but theoretically possible). They then can pass null into the ForegroundToken argument.

kilotaras 10y ago

If you're rooted xposed with xprivacy has 1. More finegrained permissions (per api call basically) 2. Ability to give/deny permission per use case or some time.