Skip to content

fix(android): explain camera permission for setup scans#98280

Closed
TurboTheTurtle wants to merge 1 commit into
openclaw:mainfrom
TurboTheTurtle:fix-98044-android-camera-permission
Closed

fix(android): explain camera permission for setup scans#98280
TurboTheTurtle wants to merge 1 commit into
openclaw:mainfrom
TurboTheTurtle:fix-98044-android-camera-permission

Conversation

@TurboTheTurtle

@TurboTheTurtle TurboTheTurtle commented Jun 30, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Closes #98044.

What Problem This Solves

When Android setup QR scanning failed because Camera permission was denied, onboarding only showed generic scanner failure copy and did not guide users to grant the permission.

Evidence

At PR head 4e9ef75fcc, focused Play and third-party unit tests pass for OnboardingFlowLogicTest. They cover camera-specific scanner copy, the app-settings recovery decision, non-camera setup errors hiding the camera settings action, and the scan-time CAMERA grant updating the final onboarding permission state.

Manual UI validation:
On sdk_gphone64_arm64, Android 16 / API 36, using the Play debug APK (versionName=2026.6.10, targetSdk=36), Camera was revoked for OpenClaw and Google Play services. Connect Gateway -> Scan setup code first showed Google scanner Camera permission required; after dismissing it, Android requested Allow OpenClaw Node to take pictures and record video?; after Don’t allow, Gateway Setup showed Camera permission is required to scan setup codes. Open Android app settings to grant Camera permission, then try again. with the Open app settings action. A follow-up UI dump after leaving the camera-specific state no longer contained Open app settings.

@openclaw-barnacle openclaw-barnacle Bot added app: android App: android size: S triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. labels Jun 30, 2026
@clawsweeper

clawsweeper Bot commented Jun 30, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs maintainer review before merge. Reviewed June 30, 2026, 6:40 PM ET / 22:40 UTC.

Summary
Updates Android onboarding QR scan failure handling to show camera-specific recovery copy, request CAMERA after a denied scanner failure, add an app-settings action, and cover the logic with unit tests.

PR surface: Other +143. Total +143 across 2 files.

Reproducibility: yes. at source level: current main maps QR scanner startup failure to generic copy while Android already declares and tracks CAMERA permission state. The contributor also posted an exact-head emulator flow for the denied-camera path, but I did not independently run an emulator in this read-only review.

Review metrics: 1 noteworthy metric.

  • Android permission state surface: 1 scan-time CAMERA request path added; 1 PermissionState update hook added. The QR setup prompt and final onboarding permission state need to stay synchronized before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #98044
Summary: This PR is the linked candidate fix for the Android onboarding camera-permission QR setup issue; the broader Android auth recovery issue and its PR are adjacent but do not replace this scanner-permission work.

Members:

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

  • none.

Next step before merge

  • No ClawSweeper repair lane is needed; the remaining action is normal maintainer review and merge decision for the focused candidate fix.

Security
Cleared: The diff changes Android onboarding permission UI and unit tests only; it adds no dependencies, workflows, package execution, secret handling, or supply-chain surface.

Review details

Best possible solution:

Merge this focused Android onboarding fix after normal maintainer review, let it close #98044, and leave broader auth recovery messaging to #98046 and #98094.

Do we have a high-confidence way to reproduce the issue?

Yes at source level: current main maps QR scanner startup failure to generic copy while Android already declares and tracks CAMERA permission state. The contributor also posted an exact-head emulator flow for the denied-camera path, but I did not independently run an emulator in this read-only review.

Is this the best way to solve the issue?

Yes, this is the best current fix shape: it stays at Android onboarding's scan/error boundary, preserves manual setup fallback, and synchronizes scan-time permission results into the existing onboarding permission owner.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 3811001d2783.

Label changes

Label justifications:

  • P2: This is a bounded Android onboarding bugfix affecting QR setup recovery while manual setup remains available.
  • rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
  • status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): Contributor emulator proof plus the successful Real behavior proof check show the after-fix denied-camera setup path with scanner failure, Android permission prompt, camera-specific copy, and the app-settings action.
  • proof: sufficient: Contributor real behavior proof is sufficient. Contributor emulator proof plus the successful Real behavior proof check show the after-fix denied-camera setup path with scanner failure, Android permission prompt, camera-specific copy, and the app-settings action.
Evidence reviewed

PR surface:

Other +143. Total +143 across 2 files.

View PR surface stats
Area Files Added Removed Net
Source 0 0 0 0
Tests 0 0 0 0
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 2 144 1 +143
Total 2 144 1 +143

What I checked:

Likely related people:

  • obviyus: Authored the merged Android QR scanner replacement and several subsequent Android setup/auth changes that define the scanner and setup-code boundary touched here. (role: feature introducer; confidence: high; commits: 45721d5dec81, cc5eb972e69a, 94bc18ad7535; files: apps/android/app/src/main/java/ai/openclaw/app/ui/OnboardingFlow.kt, apps/android/app/build.gradle.kts)
  • Solvely-Colin: Recent GitHub commit history for OnboardingFlow.kt includes Android overview and node-approval onboarding work adjacent to this setup recovery path. (role: recent Android onboarding contributor; confidence: medium; commits: 5e342c774d8d, 8e77d5e1444f; files: apps/android/app/src/main/java/ai/openclaw/app/ui/OnboardingFlow.kt)
  • joshavant: Recent remote history shows multiple Android onboarding and gateway pairing/recovery commits in the same file and user flow. (role: adjacent Android setup contributor; confidence: medium; commits: f4a5e5762e27, 109806378347, 81f4fe6c113b; files: apps/android/app/src/main/java/ai/openclaw/app/ui/OnboardingFlow.kt)
  • Agustin Rivera: Local blame points the current scanner region to a recent commit that carried the whole file into this shallow checkout, but the commit subject is unrelated to Android, so this is a weak routing signal. (role: recent current-file committer; confidence: low; commits: 587eefe5ad91; files: apps/android/app/src/main/java/ai/openclaw/app/ui/OnboardingFlow.kt)
What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works
  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

@openclaw-barnacle openclaw-barnacle Bot removed the triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. label Jun 30, 2026
@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P2 Normal backlog priority with limited blast radius. labels Jun 30, 2026
@TurboTheTurtle

TurboTheTurtle commented Jun 30, 2026

Copy link
Copy Markdown
Contributor Author

Real behavior proof

Verified on a local Android emulator from this PR head (dd279300cf93), using the Play debug APK (versionName=2026.6.10, targetSdk=36) on sdk_gphone64_arm64, Android 16 / API 36.

Flow observed:

  • Cleared ai.openclaw.app, revoked Camera for ai.openclaw.app, and revoked Camera for Google Play services to force the scanner camera-denied path.
  • Launched OpenClaw, tapped Connect Gateway, then Scan setup code.
  • Google scanner showed Camera permission required for OpenClaw Node.
  • After dismissing that dialog, OpenClaw requested Camera permission with Allow OpenClaw Node to take pictures and record video?.
  • After tapping Don’t allow, Gateway Setup showed Camera permission is required to scan setup codes. Open Android app settings to grant Camera permission, then try again. and kept the Open app settings action visible.

This verifies the denied-camera scanner failure path now leaves the user with specific recovery guidance instead of the generic scanner failure.

@TurboTheTurtle
TurboTheTurtle force-pushed the fix-98044-android-camera-permission branch from dd27930 to 95764ee Compare June 30, 2026 22:00
@TurboTheTurtle

TurboTheTurtle commented Jun 30, 2026

Copy link
Copy Markdown
Contributor Author

@clawsweeper re-review

@clawsweeper

clawsweeper Bot commented Jun 30, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

@clawsweeper clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. and removed rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. labels Jun 30, 2026
@TurboTheTurtle
TurboTheTurtle force-pushed the fix-98044-android-camera-permission branch from 95764ee to 4e9ef75 Compare June 30, 2026 22:14
@clawsweeper clawsweeper Bot added status: 🛠️ actively grinding The PR author has acted after the latest ClawSweeper review and work remains. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. and removed status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: 🛠️ actively grinding The PR author has acted after the latest ClawSweeper review and work remains. labels Jun 30, 2026
@masatohoshino masatohoshino mentioned this pull request Jul 1, 2026
Merged
@steipete

steipete commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Maintainer verdict: closing this candidate because it requests the wrong permission and does not fix the reproduced failure.

Google's Code Scanner contract is explicitly permissionless for the calling app: scanning runs in Google Play services, and OpenClaw must not request its own CAMERA permission for this flow. The shipped play-services-code-scanner:16.1.0 AAR confirms that boundary: its manifest declares no camera permission, and its delegate launches com.google.android.gms.mlkit.ACTION_SCAN_BARCODE in com.google.android.gms.

I reproduced both sides on Android 16:

  • OpenClaw CAMERA denied + Google Play services CAMERA granted: scanner opened and ran normally; the resumed activity was Google Play services' BarcodeScanningActivityProxy.
  • OpenClaw CAMERA granted + Google Play services CAMERA denied: scanner still failed. Google Play services' own dialog explicitly said to grant camera permission to Google Play services in Settings.

The PR maps every scanner failure to OpenClaw's camera state, then requests OpenClaw CAMERA and links to OpenClaw app settings. That misdiagnoses Play-services permission, module-download, unsupported-services, and other scanner failures; granting the requested permission did not recover the live failure. The contributor proof is consistent with this: it deliberately revoked Google Play services camera permission, and the first dialog was owned by that service.

The supported alternatives are already present: let Google Code Scanner own its permission UI and keep paste/manual setup available. A future focused change could distinguish scanner-module or Play-services availability using the dependency's structured failure contract, but it should not request OpenClaw camera permission. Official contract: https://developers.google.com/ml-kit/vision/barcode-scanning/code-scanner

Thank you for the careful UI work and emulator evidence; that evidence made the ownership mismatch possible to verify conclusively.

@steipete steipete closed this Jul 2, 2026
@steipete steipete mentioned this pull request Jul 2, 2026
Closed
@TurboTheTurtle
TurboTheTurtle deleted the fix-98044-android-camera-permission branch July 4, 2026 23:51
@vincentkoc vincentkoc mentioned this pull request Jul 6, 2026
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

app: android App: android P2 Normal backlog priority with limited blast radius. proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. size: S status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Android onboarding should request and explain camera permission for QR setup

2 participants

@TurboTheTurtle @steipete