Choose direct capture or delegation
If your app directly controls the camera or records audio, use the relevant APIs and permission model. If the user selects existing media or delegates capture to another app, the access requirements can differ.
The permission reference and runtime request guide describe the platform grants. A manifest declaration alone does not authorize a runtime operation on versions requiring user approval.
Request access at the right moment
| User action | Sensible request boundary |
|---|---|
| Starts voice recording | Microphone access |
| Opens an in-app scanner | Camera access |
| Starts video capture with sound | Camera and microphone with a clear explanation |
| Chooses an existing photo | Picker flow rather than automatic camera access |
Explain which feature is unavailable after denial while keeping unrelated screens usable. Do not start capture immediately on a future launch merely because a grant exists from an earlier session.
Handle lifecycle and revocation
Release capture resources when the feature stops or the lifecycle requires it. Test interruptions, another app using the camera, microphone privacy controls and permission revocation. The device may temporarily deny access even though the manifest is correct.
Do not swallow a failure and show a recording timer that implies capture is happening. Report the actual state and preserve any safely completed output.
Protect captured data
Apply Android security guidance to temporary files, sharing and retention. Avoid putting recordings into broadly accessible storage without a user reason. Do not log raw audio, images or sensitive derived content as diagnostics.
Validate the release path
Test a clean install, first denial, later grant, cancellation and a partially completed capture. APKLint can inspect camera and microphone declarations and identify unexpected SDK requests. It cannot verify sensor state, lifecycle cleanup or whether capture begins only after a deliberate user action; those require runtime tests.
Handle camera access without assuming microphone access
Consider a video-message feature that can capture both pictures and sound. A user may permit the camera while declining the microphone. Model the two capabilities separately and explain whether the app supports a silent recording. Do not show a microphone indicator or audio waveform suggesting sound was recorded when the audio input could not start.
The runtime permission guide describes checking access at the feature boundary and handling the result. A previous successful recording does not establish the current grant. Return from system settings, recreate the capture screen and check again before allocating the sensor resources.
Tie the permission response to the current recording session
Suppose the user starts capture, sees a permission dialog and navigates away before the result reaches the app. A late positive result should not start a recording on an unrelated screen. Associate the pending action with the current feature state and lifecycle, then require the appropriate deliberate action if the original session no longer exists.
Once capture begins, distinguish permission failure from device unavailability, another client using the sensor and an output-storage failure. These conditions need different recovery steps. Preserve an already completed recording only when it can be finalized safely, and clearly identify an incomplete attempt rather than leaving a playable-looking item that contains no useful media.
For capture continuing outside the visible activity, review the applicable foreground-service type requirements. Camera and microphone access have while-in-use constraints, and declaring a service type does not itself authorize starting it from every background context. Test the intended start and stop path on the supported device and target-SDK combinations.
Use synthetic images and speech for regression checks. Verify camera-only, microphone-only where meaningful, both grants, denial, screen rotation, interruption and stopping the feature. Open the resulting media independently to confirm whether it contains the expected tracks and duration. A file existing on disk is not sufficient evidence that both streams were captured.
Keep temporary output in an appropriate app-controlled location and expose it through the intended sharing flow only after completion. Remove abandoned temporary captures according to the app's retention design. Permission approval authorizes a platform capability; it does not decide when your product should retain, transmit or share a recording.
Sources and further reading
- Android Developers: Request runtime permissions
- Android Developers: Manifest.permission reference
- Android Developers: Security best practices
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
