Agree on the expected result before testing. Record the build, device, permission state and actual observation; leave a case untested when you cannot safely reproduce its starting condition.
Choose one photo task and a safe test setup
The meal-photo journal below is a fictional test specification, not a customer story or tests already performed. Its task is: open Add photo, capture an image, review it, tap Save and reopen that entry later. Cancelling before Save should create no entry.
Use an approved beta or dedicated test build on real devices. Photograph a drawn blue circle and orange square on paper: an identifiable image without faces, documents or location clues. Keep recordings free of personal notifications and account details.
Record the app build, device model, system version and initial permission state. Ask for an isolated test setup when a first-request state is unavailable. Do not uninstall a production app, clear its records or reset a phone to recreate a dialog.
Separate permission, preview and a saved record
The Flutter camera recipe separates controller initialization, preview, capture and displaying the image. Capture returns an image in a cache directory; displaying it does not prove a durable journal record exists. Save, leave and reopen the entry to check its picture and label.
Camera access, microphone access and choosing an existing photo are separate decisions. The Flutter camera plugin setup lists camera and microphone usage-description declarations for iOS. Check the pinned plugin’s requirements and audio configuration; declarations and runtime requests are not interchangeable. Do not request microphone or library access merely because a checklist says “camera.” Test any agreed photo-library import or export route separately.
Run this iOS and Android acceptance matrix
These are proposed checks for the fictional journal, not universal dialog wording. Run applicable rows separately on each target. Settings changes are deliberate tester actions, not permission nags. Replace “Untested” with the observation and evidence, or explain the unavailable setup; never count it as a pass.
| Starting condition | Action to test | Expected result for this example | Actual result |
|---|---|---|---|
| 1. Camera access not decided | Open Add photo, grant the request, capture the card and Save; reopen the entry. | Request relates to the photo task; a ready preview leads to a captured image and one reopenable record. | Untested |
| 2. Camera access not decided | Open Add photo and refuse access; leave the camera route. | A clear unavailable state replaces the preview; other journal records remain usable; no entry is falsely marked saved. | Untested |
| 3. Access previously refused | Return to Add photo without changing Settings. | Current refusal is respected; no endless prompt loop or frozen preview. Explain the available next step without demanding approval. | Untested |
| 4. Access enabled in Settings | Enable camera access for this test app; reopen it and try Add photo. | Access is checked again; the camera either initializes or reports a distinct error. Capture and Save are verified separately. | Untested |
| 5. Access revoked in Settings | After saving the card, revoke camera access; reopen the app and attempt a new photo. | Existing saved entry remains readable; new capture is unavailable, with no false success. Record any process restart. | Untested |
| 6. Preview interrupted | With the preview ready, go to the home screen and return; then cancel the draft. | Return produces a usable preview or a clear recovery state, not an unexplained frozen frame. Cancellation adds no entry. | Untested |
| 7. Temporary Android access, when offered | Choose Only this time; later reopen and check the current state before another capture. | The app does not assume lasting access. Available access allows initialization; absent access follows the appropriate request or refusal flow. | Untested |
If a capture or save fails, keep that result separate from the permission result. Include the exact visible message and the stage that failed in a mobile app bug report, rather than guessing that every black preview means “permission denied.”
Check platform differences without forcing approval
Apple’s capture-authorization guidance says to inspect status before capture and request undecided access in context. iOS remembers the response; a previous refusal is not a fresh prompt every time. Users can change access in Settings.
The camera plugin distinguishes denial, prior iOS denial without another prompt, and restricted access. Restricted access is not simply waiting for Allow. Use an authorized restricted test device or mark it untested; do not alter someone’s parental or managed-device controls.
Android’s runtime-permission guidance recommends contextual requests, checking current access each time and keeping unaffected features usable after refusal. Avoid repeated requests or coercive Settings messages. Temporary access is not a permanent grant. Revoking one-time access can terminate the process: inspect the next launch instead of assuming the original screen will resume.
Treat returning to the camera as another test
The camera plugin makes the developer responsible for camera resources when app lifecycle state changes. Granted permission does not prove the previous controller remains usable.
For row 6, distinguish backgrounding from a restart. Observe the returned preview before tapping Capture. Check loading, failure and cancellation; do not accept a frozen frame because the first capture worked.
The matrix is a sample, not exhaustive device coverage. Add orientation, camera selection or repeated-entry cases when required, with expectations agreed in the MVP scope.
Copy a prepared test note, then record what happened
This fictional prepared note contains no claimed result. Add real build and device details when testing, and share evidence through the project’s private feedback route.
Scenario: Fictional meal-photo journal, row 5.
Build / device / system: Not recorded; test not run.
Starting state: One saved colored-card entry; camera access initially allowed.
Steps: Revoke this test app’s camera access in Settings. Reopen the app. Read the saved entry, then open Add photo.
Expected: Old entry is readable; new capture reports unavailable access without claiming a save.
Actual: Untested.
Evidence: None collected.
Still unknown: Whether the process restarts, exact message and behavior on each target device.
Carry observations and unresolved cases into the handover record with the build, starting condition and result.
Connect the camera to a useful product task
For a real product example, NutriLens uses meal photos for calorie and macro estimates. Its iOS listing describes the photo workflow and optional in-app purchases. A photo estimate is not an exact measurement or an allergy-safety check. This article does not establish which plugin NutriLens uses or claim that its permission flow passed this fictional matrix.
Planning a Flutter app with a camera workflow? Explore Moocsoft’s Flutter development service with the photo task, target devices and expected refusal behavior. A concrete journey gives the development discussion more to work with than “add camera access.”
Common questions
Is granting camera permission enough to pass the test?
No. Check camera initialization, a usable preview, successful capture and the product’s save-and-reopen behavior separately. A granted permission does not prove those later steps worked.
Should the app ask again every time someone refuses camera access?
No. Respect the current platform state and the refusal. iOS remembers its previous response, and Android guidance discourages coercive requests. Keep unaffected features usable and explain the actual available options.
Does a still-photo workflow need microphone permission?
Do not infer that from the word camera. Review the pinned plugin’s setup and audio configuration, and test the permissions the actual implementation requests. Microphone access and camera access are separate.
Can I clear an installed app’s data to recreate the first prompt?
Do not clear production records, uninstall a production app or reset a phone for this checklist. Ask for an isolated test build and safe setup; mark a starting condition untested if you cannot prepare it safely.
References and further reading
Published by Moocsoft, an independent Flutter development studio. Examples and worksheets are illustrative. Project scope, platform requirements and release responsibilities need to be agreed for each project.