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:
| Field | Example question |
|---|---|
| Permission name | What exact constant is declared? |
| Feature | Which user action needs it? |
| API range | On which supported versions does this path apply? |
| Grant mechanism | Runtime dialog, special settings or another controlled mechanism? |
| Fallback | What remains usable after denial? |
| Source | Did the app or a dependency add it? |
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.
Explain one recording permission from feature to fallback
For a voice-note feature, inventory RECORD_AUDIO against the explicit record action. Identify the application or SDK code that opens the microphone, the supported API paths and what the user sees after refusal. A useful fallback might preserve text notes while disabling recording. Describing the entire app as unusable would be inaccurate if its other functions do not need audio access.
Repeat that analysis for each declaration instead of treating the total number of dangerous permissions as a verdict. Two permissions with clear, necessary feature boundaries can be better justified than one unnecessary permission collected at startup. Conversely, an app with no dangerous permissions can still transmit account or usage data through ordinary networking.
Check the specific access the operation needs
Android's permission overview warns against assuming stable permission-group behavior. Build the feature around its documented permissions and API requirements rather than inferring that granting one related permission grants all others. Use current platform references when media, location or notification access changes across supported releases.
For voice notes, test a first request, a declined request, a later settings grant and revocation while the app remains installed. Check that the recording indicator matches actual microphone use and that a failed start does not produce a fake saved note. If access ends during recording, preserve only a valid output according to the recorder's supported error contract.
When a dependency update introduces a declaration, trace its source through the merger report and determine whether the corresponding feature is enabled. Removing the declaration without reviewing the SDK path can create a runtime failure; retaining it without understanding the path leaves the audit incomplete. Record whether each permission was removed, narrowed or justified, with the exact candidate artifact. The conclusion should explain the user's action, accessed resource and denial behavior, while separate data-flow review establishes collection, sharing and retention practices.
Sources and further reading
- Android Developers: Permissions overview
- Android Developers: Manifest.permission reference
- Android Developers: Request runtime permissions
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
