[Due for payment 2026-06-01] [$250] [Android] Receipt capture produces mostly black/blank image

[MelvinBot]

Slack thread: https://expensify.slack.com/archives/C05LX9D6E07/p1778675274739809

Description

When capturing a receipt on Android, the resulting image is sometimes mostly or entirely black/blank. This has been reported by multiple users and appears to be intermittent — taking a new photo (which creates a new expense) works as a workaround.

Steps to Reproduce

1. Open the Expensify app on Android
2. Create a new expense and use the camera to capture a receipt
3. Observe that the captured image is mostly or entirely black

Expected: The captured receipt image should be clear and usable.
Actual: The image is ~90% black/blank. Retaking the photo (creating a new expense) resolves it.

Additional Context

• Reported on Android devices only so far
• There is speculation this may be related to a snapshot-based capture change on Android (though the related PR Show thumbnail preview while receipt image loads #88575 has not been deployed yet, there may be other snapshot-related changes in play)
• Multiple users have experienced this issue independently

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054645997761418508
• Upwork Job ID: 2054645997761418508
• Last Price Increase: 2026-05-13

Issue Owner

Current Issue Owner: @jayeshmangwani

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @jayeshmangwani (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022054645997761418508

[aswin-s]

Please re-state the problem that we are trying to solve in this issue.

When capturing a receipt on Android in portrait orientation without flash, the resulting image is often mostly or entirely black/blank, rendering it unusable for expense processing. The user must retake the photo (creating a new expense) to get a usable image. This does not occur on iOS or when the device is in landscape mode or flash is enabled.

What is the root cause of that problem?

The bug originates in src/pages/iou/request/step/IOURequestStepScan/captureReceipt/index.android.ts in the captureReceipt function (lines 3–14). When the device is not in landscape mode and flash is disabled, the code falls back to camera.takeSnapshot({quality: 85, path}). React Native Vision Camera's takeSnapshot reads directly from the GPU preview surface, and on Android this operation is known to suffer from GPU surface buffer timing issues and read race conditions that intermittently produce black/blank frames. The "retry by retaking the photo" workaround pattern matches this exact failure signature.

In contrast, the iOS implementation unconditionally uses camera.takePhoto, which does not have this issue. Additionally, the same Android file already uses takePhoto in its landscape and flash-enabled branches, confirming that takePhoto is the correct approach.

App/src/pages/iou/request/step/IOURequestStepScan/captureReceipt/index.android.ts

Lines 3 to 14 in f08b45e

	const captureReceipt: CaptureReceipt = (camera, {flash, hasFlash, isPlatformMuted, path, isInLandscapeMode}) => {
	const useFlash = flash && hasFlash;
	if (useFlash || isInLandscapeMode) {
	return camera.takePhoto({
	flash: useFlash ? 'on' : 'off',
	enableShutterSound: !isPlatformMuted,
	path,
	});
	}
	return camera.takeSnapshot({quality: 85, path});
	};

App/src/pages/iou/request/step/IOURequestStepScan/captureReceipt/index.ios.ts

Lines 3 to 11 in f08b45e

	const captureReceipt: CaptureReceipt = (camera, {flash, hasFlash, isPlatformMuted, path}) => {
	return camera.takePhoto({
	flash: flash && hasFlash ? 'on' : 'off',
	enableShutterSound: !isPlatformMuted,
	path,
	});
	};
	export default captureReceipt;

What changes do you think we should make in order to solve the problem?

1. File: src/pages/iou/request/step/IOURequestStepScan/captureReceipt/index.android.ts
   Function: captureReceipt
   Change: Remove the conditional branch that calls takeSnapshot and replace it with an unconditional call to takePhoto for all capture scenarios (portrait, landscape, with or without flash). This aligns the Android default path with the already-working flash and landscape branches, and eliminates the GPU surface race condition.

   Exact edit: Replace lines 3–14 with:

   const captureReceipt: CaptureReceipt = (camera, {flash, hasFlash, isPlatformMuted, path}) => {
       if (!camera) {
           return Promise.reject(new Error('Camera is not available'));
       }
       const useFlash = flash && hasFlash;
       return camera.takePhoto({
           flash: useFlash ? 'on' : 'off',
           enableShutterSound: !isPlatformMuted,
           path,
       }).catch((error: Error) => {
           throw new Error(`Failed to capture receipt: ${error.message}`);
       });
   };

   The null guard on camera prevents a runtime crash if the camera reference is not yet initialized when captureReceipt is invoked. The .catch re-throws with a descriptive message so callers can surface a user-facing error (e.g. permission denied, device limitation) rather than receiving a silent rejection.

   This removes the isInLandscapeMode parameter and the conditional logic, so all calls now route through takePhoto.

Blast radius: The change affects the two call sites that invoke captureReceipt. Before verifying that no other references exist, grep for captureReceipt and isInLandscapeMode across the repository to confirm the full set of callers:

• src/pages/iou/request/step/IOURequestStepScan/components/Camera/index.native.tsx line 222
• src/pages/iou/request/step/IOURequestStepScan/hooks/useCapturePhoto.ts line 161

Both call sites pass isInLandscapeMode today. After this change, that argument must be removed from each invocation. If any additional callers surface during the grep, the same argument removal applies. No other code depends on this parameter beyond passing it into captureReceipt.

What alternative solutions did you explore?

Adding a black-frame detection heuristic on top of takeSnapshot that retries if the image is detected as mostly black. This was rejected because: (1) Detecting "mostly black" JPEG content in JavaScript requires pixel decoding, which is unreliable for low-light receipts and cannot distinguish between a legitimately dark receipt and a black-frame bug; (2) It leaves the underlying GPU surface race condition in place, only masking the symptom; (3) The performance argument for preferring takeSnapshot is weak—takePhoto already works reliably in landscape and with flash, and iOS uses it universally without complaints.

[aswin-s]

Updated the proposal above to tighten 3 edge cases (additional guards and broader coverage).

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

The Android receipt scanner uses two different capture paths. When flash is enabled or the device is in landscape, it captures the receipt with camera.takePhoto(). But in the common portrait/no-flash case it captures with camera.takeSnapshot() instead:

App/src/pages/iou/request/step/IOURequestStepScan/captureReceipt/index.android.ts

Lines 3 to 13 in 4378b1e

	const captureReceipt: CaptureReceipt = (camera, {flash, hasFlash, isPlatformMuted, path, isInLandscapeMode}) => {
	const useFlash = flash && hasFlash;
	if (useFlash || isInLandscapeMode) {
	return camera.takePhoto({
	flash: useFlash ? 'on' : 'off',
	enableShutterSound: !isPlatformMuted,
	path,
	});
	}
	return camera.takeSnapshot({quality: 85, path});

That snapshot path is the source of the intermittent black/blank receipts. The scanner renders a real VisionCamera preview with photo enabled:

App/src/pages/iou/request/step/IOURequestStepScan/components/CameraViewport.tsx

Lines 99 to 109 in 4378b1e

	<NavigationAwareCamera
	ref={camera}
	device={device}
	format={format}
	fps={fps}
	style={styles.flex1}
	zoom={device.neutralZoom}
	photo
	cameraTabIndex={1}
	forceInactive={isAttachmentPickerActive || didCapturePhoto}
	onInitialized={onInitialized}

However, VisionCamera’s Android takeSnapshot() captures the preview view bitmap, not a camera photo frame. That makes the saved image dependent on the Android preview rendering surface at the exact capture moment. When that preview bitmap is black or incomplete, Expensify still treats it as a successful receipt image and uploads/saves it through the normal capture flow:

App/src/pages/iou/request/step/IOURequestStepScan/hooks/useCapturePhoto.ts

Lines 162 to 180 in 4378b1e

	const path = getReceiptsUploadFolderPath();
	captureReceipt(cameraRef.current, {flash, hasFlash, isPlatformMuted, path, isInLandscapeMode})
	.then((photo: PhotoFile) => {
	setDidCapturePhoto(true);
	const transaction =
	isMultiScanEnabled && initialTransaction?.receipt?.source
	? buildOptimisticTransactionAndCreateDraft({
	initialTransaction,
	currentUserPersonalDetails,
	reportID,
	})
	: initialTransaction;
	const transactionID = transaction?.transactionID ?? initialTransactionID;
	const source = getPhotoSource(photo.path);
	const filename = photo.path;
	endSpan(CONST.TELEMETRY.SPAN_RECEIPT_CAPTURE);

What changes do you think we should make in order to solve the problem?

Use camera.takePhoto() for Android receipt capture in every orientation and flash state. The receipt scanner is capturing an actual receipt document, so the app should always use the camera photo output rather than a preview-view screenshot.

Required change:

• Update src/pages/iou/request/step/IOURequestStepScan/captureReceipt/index.android.ts.
• Remove the Android-only takeSnapshot() branch.
• Keep the existing flash behavior and enableShutterSound behavior.
• Leave the shared receipt upload, optimistic transaction, thumbnail generation, and navigation flow unchanged.

Tests that should be added/covered:

• Android native manual test: create a scan receipt expense in portrait with flash off and verify the receipt image is not black/blank.
• Android native manual test: repeat receipt capture with flash on.
• Android native manual test: repeat receipt capture in landscape.
• Regression check: multi-scan still adds each captured receipt and single-scan still navigates to confirmation.

I considered adding validation to reject mostly black images after capture, but that would only detect the bad output after the faulty snapshot path already ran. It would also add image-processing complexity and still force users to retake receipts. The root-cause fix is to stop using Android preview snapshots for receipt capture and always use the real photo capture path.

What alternative solutions did you explore? (Optional)

[github-actions]

⚠️ @nabi-ebrahimi Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[dilshodmackbook-sketch]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.