Android Dangerous Permissions: Build a Version-Aware Inventory

Do not maintain a timeless pasted list

The permission reference documents protection levels, API introductions and restrictions. A list copied from an old Android release can omit newer media or notification permissions and include access patterns that no longer work as described.

Build a release-specific inventory instead:

Distinguish the protection mechanisms

INTERNET is not requested through a dangerous-permission dialog. Overlay access uses a special settings flow. Signature or privileged permissions are not ordinary runtime requests. Treating all manifest entries identically produces broken permission screens and misleading audits.

The permissions overview is a better starting model than a scanner's count of “risky” names.

Request access at the feature boundary

Ask when the person invokes the feature, explain why it needs access, and handle refusal without blocking unrelated functions. Do not request camera, microphone, location and contacts at startup merely because some future feature might use them.

Use current runtime-permission APIs and check again at the point of use. Grants can change outside your app, and a previously successful request is not permanent evidence of access.

Audit the merged release

Inspect the final manifest, not only your module's source manifest. SDKs can contribute permissions during merging. Removing a permission requires checking whether the corresponding feature or dependency still expects it.

Test fresh install, denial, later grant, revocation and supported older devices. Include partial or limited access where the platform supports it.

Interpret APKLint findings

The Dangerous Permissions Checker helps identify declarations worth reviewing. It cannot determine whether the user currently granted them or whether the app uses the data as disclosed. Combine package inspection with runtime testing and a feature-level explanation for each permission.