Recover When Android Permissions Change During an AI Task

Direct answer

Permission revocation during an active local-AI task is a lifecycle transition, not just a failed request dialog. A camera, microphone, or user-selected file may become inaccessible while capture, preprocessing, inference, persistence, or export is in progress. Android permission guidance says apps should verify the access needed by a feature and gracefully degrade when users deny or revoke it. Android documents that revoking certain one-time permissions can terminate the app process. Therefore, the application must be correct both when a callback reports access loss in a live process and when the next launch finds only durable state; an in-memory task flag or native handle cannot be assumed to survive. Define ownership by stage. The capture component owns active camera or recorder resources; preprocessing may own a copied image or audio buffer; an inference task may hold a derived tensor; persistence may own a transaction. On revocation, stop accessing the protected source, cancel or classify work according to the product contract, close the resources the app owns, and preserve only content already committed under the user’s earlier action. Do not continue capture silently, and do not delete unrelated user-authored history as a repair shortcut. If access was revoked after raw bytes were copied into app memory, the policy for that copy must still be explicit; permission revocation does not automatically decide every retention question. Test camera, microphone, and imported content separately. For each, trigger revocation during acquisition, preprocessing, an inference call, result persistence, and export. Include a one-time grant path, a settings-based revoke, a denial before task start, and process recreation after revocation. Record the permission state before the operation, the first failed boundary, task/request ID, completed segments or pages, cancellation acknowledgement, cleanup result, and UI state. Avoid claiming that a particular permission callback always arrives before process death; rely on rechecking access when resuming a protected action. After relaunch, reconstruct only durable state that is valid without the revoked resource. Mark interrupted work incomplete, make prior confirmed output distinguishable from a partial result, and require a fresh permission check before accessing the source again. If a task can resume from an app-owned copy, document that boundary and test deletion/retention behavior. If it must restart from the original file or camera, explain the user action required. Never persist permission grants as if they were permanent authorization. The useful release evidence is a set of stage-by-stage tests, not a claim that every task recovers automatically. The repository fact cards describe Android access boundaries and current Cove lifecycle states, but they do not establish every product screen handles mid-task revocation. Use synthetic or consented fixtures; diagnostics should retain error stage and request identity, not photo, audio, or document content. The conclusion must be bounded to app build, Android version, permission type, task stage, and recovery path actually tested.

Microphone access disappears during an offline voice note

A user starts a private recording under a temporary microphone grant. Several PCM segments are complete while the next segment is being captured; a system permission change terminates the process or prevents further access.

Decision

Preserve only committed segments, mark the current segment incomplete, release owned resources, and recheck permission after relaunch before offering resume or restart.

Expected outcome

The user sees what was saved and what needs a new permission action; no stale recorder or native handle is reused.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Permission transition matrix
• Injected revocation fixtures
• Stop, cleanup, disclosure, and retry behavior

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Map protected resources and owners. List each protected source and its task stages: camera/audio/file access, preprocessing copies, inference inputs, database writes, and exports. Assign an owner and cleanup action to each resource.
2. Define state transitions for revocation. Specify how the task responds to denial, revocation, access exception, cancellation, and process death. Distinguish completed output from partial or uncertain work; do not silently keep capturing.
3. Inject revocation at each task boundary. Test during acquisition, preprocessing, inference, persistence, and export for camera, microphone, and imported-file flows. Include one-time permission, Settings revocation, pre-start denial, and relaunch.
4. Verify cleanup and durable-state recovery. Assert the app stops using the protected source, releases camera/recorder/session/buffer resources it owns, and restores only persisted state. Recheck permission before retrying the protected action.
5. Review user messaging and diagnostics. Tell the user what completed, what was interrupted, and which action is required. Keep logs to stage, permission class, request ID, and cleanup outcome; exclude raw media and file content.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Revocation is tested separately at capture, preprocessing, inference, persistence, and export boundaries for each applicable permission type.
• Completed results remain distinct from incomplete work; no revoked source is accessed silently after the transition.
• Process-death tests rebuild state without persisting native handles or treating prior permission as permanent authorization.
• Recovery messaging and diagnostics identify the tested permission/task stage without exposing user content.

Decision table

Failure patterns to prevent

• Assuming a grant lasts through the task
• Persisting data after the user revokes access

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• Android runtime permission request and revocation guidance
• Android 11 one-time permissions and permission updates

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions