Find the source of the permission
Inspect the merged release manifest and dependency contributions. A library may introduce a permission that your app never intentionally requests. Remove unused access through a tested dependency or manifest change rather than writing a justification for an unnecessary capability.
Keep normal runtime permissions, special access and restricted Play-policy categories separate. They do not all use the same declaration form or eligibility rules.
Test a narrower design first
Examples include using the system photo picker instead of broad media access, a document picker instead of all-files access, or package-specific queries instead of broad app visibility. The correct alternative depends on the actual task.
| Evidence for a declaration | What to show |
|---|---|
| Core feature | User-visible purpose matching the store listing |
| Access scope | Exact permission and data used |
| Alternatives | Why a narrower supported API is insufficient |
| Disclosure | What the user sees before sensitive access |
| Demonstration | Reproducible instructions or requested video |
A vague statement such as “needed for app performance” does not explain why broad file access is necessary.
Submit against the reviewed build
Use the applicable declaration in Play Console's app-content workflow and answer for the release being submitted. Make sure reviewers can reach the feature with the provided account and instructions.
If a form is unavailable, first check the detected permission, app state and account permissions. Do not add unrelated permissions merely to trigger a form.
Verify denial and withdrawal
The app should handle users refusing or later removing access. Do not hide essential account or deletion controls behind an unnecessary permission gate.
APKLint's manifest and policy tools can surface declarations and review questions. They cannot approve restricted permission use or observe every runtime flow.
Consult the current sensitive-permission policy for the exact category. Keep the justification tied to the implemented product, and revisit it when the feature, SDK or distribution audience changes.
Sources and further reading
Reference review: 22 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
