microg / microg/GmsCore

Per-feature permission management

Open
#2,669 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Java
Stars
14.6k
Forks
3.2k
Avg merge
12d 11h
Merged PRs (30d)
4

Description

Is your feature request related to a problem? Please describe.
Currently microG defaults to being granted a bunch of permissions, a lot of which I have been able to live without. e.g. Contacts, Nearby devices, Media permissions, Body Sensors and don't seem to affect any of the features I use anyway.

Describe the solution you'd like
Instead of recommending granting every permission requested by microG, I believe it would be nice to have a per-feature setup, where if the user chooses the enable that feature, that feature will have their own little menu for what permissions it needs to work. e.g. Cloud Messaging would need battery restrictions to be off.

Describe alternatives you've considered
Nothing else I've considered... I don't see immediately a better way to decrease the amount of permissions microG uses by default

Additional context
microG can be used unprivileged officially in LineageOS and DivestOS, and it works fine for most people's use cases; better permission control over this would be beneficial, since it's something that a lot of apps communicate with.

There are a few features I believe are just there, no way to disable or enable, e.g. SMS code auto-completion which would require SMS access, etc. Might make this a bit more complicated

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points. Start by inventorying which microG features request or depend on permissions and system settings, then define the per-feature controls and acceptance criteria before choosing an implementation path.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, java
Domain
mobile
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.