The gap
The barcode surface was validated for #1042 on a headless emulator, and one link in the chain could not be exercised there: the optical decode itself.
What was proven on device (PR #1048's build, Pixel_10_Pro / Android 17):
- The camera permission round-trip through the real system dialog —
CAMERA went granted=false → granted=true.
- The camera actually starts and streams:
Camera2CaptureSequence-1 submitted via androidx.camera.camera2.pipe.
- Everything downstream of a decoded barcode string, via the scanner's "Type code manually" path (
scanner-manual-entry-submit): 3017620422003 resolved to Nutella, 539 kcal/100 g, 57.5 g carbs, 30.9 g fat, 6.3 g protein, with product image, from Open Food Facts.
What was not proven: that the scanner's detection callback fires on a real barcode. The AVD's virtual camera renders no scannable scene, so the preview streams an empty frame forever and the decode path is never entered. The manual-entry route deliberately bypasses exactly that step.
So the chain is verified either side of the decode, and unverified at it.
Why it is worth one pass rather than nothing
The risk is low — the dependency work in #1048 does not touch the scanner plugin's decode path, and the camera pipeline demonstrably initialises. But "camera opens" and "camera decodes" are different claims, and only the first has evidence behind it. The failure mode this would catch is a plugin or CameraX change that streams frames the analyzer never receives, which looks exactly like a user holding the phone wrong.
What to do
On real hardware, scan a physical barcode (any packaged product with an Open Food Facts entry) and confirm the product screen opens without going through manual entry. That is the whole test.
Acceptance criteria
Blocked by
Nothing. Needs a physical device, not a code change.
The gap
The barcode surface was validated for #1042 on a headless emulator, and one link in the chain could not be exercised there: the optical decode itself.
What was proven on device (PR #1048's build, Pixel_10_Pro / Android 17):
CAMERAwentgranted=false→granted=true.Camera2CaptureSequence-1submitted viaandroidx.camera.camera2.pipe.scanner-manual-entry-submit):3017620422003resolved to Nutella, 539 kcal/100 g, 57.5 g carbs, 30.9 g fat, 6.3 g protein, with product image, from Open Food Facts.What was not proven: that the scanner's detection callback fires on a real barcode. The AVD's virtual camera renders no scannable scene, so the preview streams an empty frame forever and the decode path is never entered. The manual-entry route deliberately bypasses exactly that step.
So the chain is verified either side of the decode, and unverified at it.
Why it is worth one pass rather than nothing
The risk is low — the dependency work in #1048 does not touch the scanner plugin's decode path, and the camera pipeline demonstrably initialises. But "camera opens" and "camera decodes" are different claims, and only the first has evidence behind it. The failure mode this would catch is a plugin or CameraX change that streams frames the analyzer never receives, which looks exactly like a user holding the phone wrong.
What to do
On real hardware, scan a physical barcode (any packaged product with an Open Food Facts entry) and confirm the product screen opens without going through manual entry. That is the whole test.
Acceptance criteria
Blocked by
Nothing. Needs a physical device, not a code change.