Use the permission API for ordinary runtime grants
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.
Check when recording begins, not only when the app starts
Imagine a notes screen that remains open while the user switches to settings and revokes microphone access. A startup-only check still says recording is available. Recheck the required grant when the user presses Record, then request it in context or display the intended unavailable state. Keep an old grant value out of the source of truth.
The permission workflow distinguishes checking a grant from requesting one. A utility that returns a boolean should not unexpectedly open a system dialog or start recording as a side effect. Let the screen owning the user action decide what explanation and request are appropriate.
Treat a successful check as one condition of the operation
Even with the grant, the microphone can be unavailable or the recorder can fail to initialize. Handle the documented API result and release partially created resources. Show separate permission and recording errors where that distinction helps the user recover. Do not produce an empty file and label it a completed recording simply because the grant check passed.
For a chosen document, use the URI-access contract instead of demanding every storage permission. For an overlay or exact alarm, use the specific capability check and settings flow. A single helper named hasAllPermissions can mistakenly block unrelated features or report success for a capability it never actually checked.
Test a sequence that preserves the installation: grant, record, stop, revoke in settings, return and record again. Include a recreated activity and a recorder initialization failure. Confirm that old success messages and download actions are cleared when the new attempt fails. Redact diagnostics while retaining enough information to distinguish absent access from an implementation error. Keep the declaration inventory separately, since an APK inspector cannot observe the current permission state of a visitor's device. The completed implementation should make its access decision from current platform evidence and still handle the operation's own failure paths without claiming that a permission check guarantees success.
Sources and further reading
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
