Manifest & Permissions

Check an Android Permission at the Point of Use

Check an Android permission immediately before the operation that needs it. A manifest declaration describes intended access; a stored boolean describes the past. Neither is a reliable substitute for the current platform grant state.

By Updated 2 min read

Use the permission API for ordinary runtime grants

KOTLIN · REFERENCE EXAMPLE
val canRecord = ContextCompat.checkSelfPermission(
    context,
    Manifest.permission.RECORD_AUDIO
) == PackageManager.PERMISSION_GRANTED

This fragment checks a grant; it does not request one. If access is missing, offer the relevant permission flow when the user starts recording, or provide an alternative that does not require recording.

The runtime-permission documentation describes request and rationale handling. Keep those decisions in the feature's UI rather than scattering dialogs throughout utility methods.

Do not use one check for every access type

Access Appropriate approach
Ordinary runtime permission Check the permission grant and request in context
Draw over other apps Check the special-access API and settings flow
Exact alarm access Check the alarm-specific capability where required
Accessibility service Check the service's enabled state and explicit user setup
Selected document or photo Use the granted URI access, not a broad storage assumption

A generic hasAllPermissions() helper can obscure these distinctions and accidentally demand unnecessary access.

Design for a race or revocation

Even a successful check is not a lifetime guarantee. Access can change while the app is paused, or the operation may fail for another reason such as a disconnected device or unavailable sensor.

Handle the operation's documented exceptions and error results. Do not silently swallow every SecurityException; log a redacted diagnostic and show a meaningful feature-level message so a missing declaration or programming error remains discoverable.

Test without resetting the app each time

Grant access, perform the action, revoke it in settings and return to the same running app. This reveals code that only checks at startup. Also test a recreated activity and a restored screen after process death.

Audit the declaration separately

APKLint's Dangerous Permissions Checker can review which permissions the app asks for and whether they warrant attention. It cannot read the current grants on a visitor's phone. Use the checker for manifest inventory and the platform APIs for runtime state.

Sources and further reading

  1. Android Developers: Request runtime permissions
  2. Android Developers: Permissions overview

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.

APKLint

Android inspection tools and practical release guides. About APKLint · Report a correction