Android Permission Review for Local AI

Direct answer

A permission review for an Android AI app should connect each capability to the exact feature that needs it, the moment it is requested, what the app can do when access is denied, and what happens if access later changes. “Local model” is not a permission category and does not remove the app's responsibility for camera, microphone, files, notifications, or network access. `ANDROID-PRIVACY-01` and `PRIVACY-01` establish those boundaries: processing location and application data handling are separate questions. Review the manifest, runtime requests, content-provider grants, settings intents, and any platform/service paths together. Start with an inventory, not a permission checklist copied from a different product. For each permission or URI grant, record the user-visible feature, the precise operation, the smallest scope available, and whether it is required at all. A camera capture feature may need camera access only when the user opens capture; importing an image with the system document picker may follow a different access route. Audio recording is distinct from speech recognition, playback, and transcription. A permission in the manifest does not show that data is uploaded, while the absence of one permission does not prove that all content stays local. These conclusions require inspecting actual request code and destinations. Ask at the point of need and explain the immediate consequence in plain language. If the user denies access, preserve a usable alternative when the feature supports one, such as selecting an existing image instead of taking a new photo. Do not repeatedly prompt after denial or block unrelated app features. Where Android offers one-time or limited access, test what happens when it expires, the activity is paused, process recreation occurs, or the user revokes access in settings. Treat a returned URI as a capability with an owner and lifetime; do not replace scoped user selection with broad storage access for convenience. Permission state is not a one-time setup fact. Re-check before the operation that requires it, handle SecurityException and provider failures as expected state transitions, cancel dependent work, close open resources, and make the next action clear. If access is revoked while capture, preprocessing, inference, persistence, or export is in flight, decide whether the operation can safely finish from already copied data or must stop. Do not continue reading a source that the user has withdrawn access to, and do not silently preserve derived output unless the retention contract permits it. Permission revocation does not automatically erase a file the app had already copied into its own storage; that is a separate deletion policy. Test the full state matrix on the Android versions and target SDKs the product actually supports; do not turn a local test into a universal device-compatibility claim. Include fresh install, grant, deny, deny again, limited or one-time grant where relevant, revocation in Settings, app backgrounding, process recreation, and return to the feature. Verify visible status, cleanup, retry, and absence of stale output. Then review the app's network behavior independently. Android Network Inspector can help with supported request libraries, but permission results and an empty capture are not a substitute for code and dependency review. Finally, remove stale declarations when a feature is removed and check merged manifests from dependencies. Keep rationale text, privacy disclosures, and behavior aligned. The outcome should be a capability-to-permission table and recorded tests—not a claim that an app is private merely because it asks for few permissions. A narrower permission surface can reduce access opportunities, but only source review and behavior tests show what the application actually does with data it can access.

An image feature needs both capture and import paths

A team supports taking a new picture and selecting an existing image for a local analysis flow. The current implementation requests camera access at launch and has no explicit behavior documented for revocation during analysis.

Decision

Separate capture permission from picker-granted file access, request each only at its corresponding action, and define cancellation and cleanup on revocation.

Expected outcome

Reviewers can see why each capability exists and can test the denied, revoked, and alternate-input paths without inferring network behavior from the permission list.

Evidence to collect

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

• Manifest inventory
• Denied-permission behavior
• Removed-feature cleanup

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

Implementation workflow

1. Inventory declared and effective access. Read the app manifest and merged dependency manifest, runtime requests, system picker use, persisted URI grants, and settings flows. For each item write the user action, data object, operation, scope, and owner.
2. Reduce scope and move requests to context. Remove unused declarations. Request a capability when the user selects the feature that needs it, explain the immediate purpose, and prefer system-mediated selection when it fits instead of broad filesystem access.
3. Specify denial and expiry behavior. For fresh denial, repeated denial, one-time grant expiry, settings revocation, and provider failure, define whether the action is unavailable, can use an alternate input, or can resume after a new grant.
4. Inject revocation during each sensitive stage. Exercise revocation during capture, preprocessing, inference, save, and export. Cancel dependent work where required, close descriptors and image/audio resources, and show which result—if any—was already committed.
5. Audit data flow separately. Inspect local storage, backup, diagnostics, and request destinations independently of the permission matrix. Capture supported networking and review dependencies; document limits of the capture tool.

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

Acceptance criteria

• Every permission or URI grant maps to a feature and operation; unused manifest declarations are removed or explicitly justified.
• Denial, temporary expiry, Settings revocation, and in-flight revocation produce a defined user-visible state and close owned resources.
• The privacy statement distinguishes access permission from upload, retention, backup, and deletion, with each latter claim supported by separate evidence.

Decision table

Failure patterns to prevent

• Permission list as transmission proof
• Hidden remote fallback

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
• Request runtime permissions
• Android security and privacy overview
• Android Photo Picker

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

Frequently asked questions