Use the torch and a snapshot for Android flash scans by OlimpiaZurek · Pull Request #104840 · Expensify/App

OlimpiaZurek · 2026-10-23T12:07:51Z

Explanation of Change

On Android, a scan with flash on takes a full photo, because a snapshot can't fire the flash. The camera meters the pre-flash first, so the photo takes about a second, and these captures make up the slow tail of ManualShutterToConfirmation.

With the new scanFlashTorch beta, turning flash on lights the torch instead, and the shutter takes a snapshot of the lit preview. The existing background upgrade then replaces it with a full photo, the same as for a scan without flash. This PR only changes Android single scans that run the upgrade. Multi-scan, skip-confirmation and edit-receipt keep the flash photo, and so does iOS.

Local p95 on one Android phone, 15 captures each:

	Flash photo	Torch snapshot
`ManualReceiptCapture` p95	1069ms	167ms
`ManualShutterToConfirmation` p95	2238ms	1137ms

In production the Android p95 of ManualShutterToConfirmation is 884ms while p90 is 458ms, and the flash captures account for that gap. We estimate the p95 drops to about 570ms once they go through the snapshot path.

Fixed Issues

$ #104482
PROPOSAL:

Tests

Requires the scanFlashTorch beta. Use a paper receipt.

Android:

Tap + > Create expense > Scan.
Tap the flash button. Verify the light on the back of the phone turns on and stays on.
Point the camera at the receipt and tap the shutter. Verify the confirmation page opens right away and the receipt image is bright and readable.
Verify the light on the back of the phone turns off a few seconds later.
Choose a recipient, submit the expense, and verify SmartScan fills in the merchant and total.
Go back to Scan, turn multi-scan on, turn flash on, and take a photo. Verify the flash fires once, as before.
Tap the flash button again to turn flash off. Verify the light turns off.

iOS:

Tap + > Create expense > Scan and turn flash on.
Take a photo. Verify the flash fires as before and the light doesn't stay on.

Verify that no errors appear in the JS console

Offline tests

QA Steps

Same as tests

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

codecov · 2026-10-23T12:13:53Z

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/CONST/index.ts	`95.90% <ø> (ø)`
src/libs/cameraCapture/platformConfig/index.ios.ts	`100.00% <ø> (ø)`
src/libs/cameraCapture/platformConfig/index.ts	`0.00% <ø> (ø)`
...st/step/IOURequestStepScan/captureReceipt/index.ts	`100.00% <100.00%> (ø)`
...RequestStepScan/utils/shouldLightFlashWithTorch.ts	`100.00% <100.00%> (ø)`
...RequestStepScan/components/Camera/index.native.tsx	`89.07% <93.93%> (+0.91%)`	⬆️
...p/IOURequestStepScan/components/CameraViewport.tsx	`0.00% <0.00%> (ø)`
... and 11 files with indirect coverage changes

OlimpiaZurek · 2026-10-26T08:00:27Z

@MelvinBot review

OlimpiaZurek · 2026-10-26T08:00:48Z

@codex review

chatgpt-codex-connector · 2026-10-26T08:01:08Z

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-26T13:35:33.135616Z	`fe1d4b9`	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

MelvinBot · 2026-10-26T08:05:53Z

Review

The capture logic and fallback look right. One issue needs a fix: the torch doesn't come back after the camera restarts, so the beta stops working for every scan after the first.

1. The torch is not re-lit when the camera becomes active again

useTorchModeUpdater in VisionCamera only calls setTorchMode when controller or torchMode changes. Neither changes when the session stops and starts:

NavigationAwareCamera/Camera.tsx:13 toggles only isActive on blur, after a capture, or when the attachment picker opens.
CameraX turns the torch off when the camera closes and does not restore it when the camera reopens.
flash survives focus changes (useNativeCamera.ts:68), so isTorchRequested stays true and the torchMode prop stays 'on'.

Here is how to reproduce it: turn flash on, scan, go back from confirmation, and scan again. The flash icon shows on, but the torch is dark. The capture logs not_lit and takes the slow flash photo. Opening and cancelling the attachment picker, or backgrounding the app, has the same effect. The fallback keeps receipts readable, but production data will undercount the speedup.

Suggested fix: pass an onStarted handler down to VisionCamera. When isTorchRequested is true, it should call camera.current?.controller?.setTorchMode('on') and reset torchRequestedAt.

2. `torchRequestedAt` measures from the toggle, not from when the torch lit

Same root cause. Camera/index.native.tsx:99-105 records the time only when isTorchRequested flips. After a restart, the 500 ms settle check at L177-L183 uses a stale timestamp. A torch that just relit could pass the check before the exposure adjusts. Resetting the timestamp in the onStarted fix above covers this.

3. Minor: `torchMode='off'` goes to devices without a torch

CameraViewport.tsx:176 now sends setTorchMode('off') on every controller, for all users. iOS ignores 'off' when there's no torch. On Android, CameraX's enableTorch likely rejects with "No flash unit" whatever the value, which would log [Camera] VisionCamera error on every camera start on those devices. Consider passing undefined when !device.hasTorch. I haven't checked this on a device.

Nits

isTorchOn in CameraViewportProps has no doc comment, but the props around it do.
The torch fallback reason is only logged. To measure not_lit and settling rates during the beta in Sentry, add it as a span attribute on ManualReceiptCapture.

view run

melvin-bot · 2026-10-26T13:19:41Z

@marufsharifi Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: fe1d4b9dfe

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-10-26T13:35:30Z

+        torchRequestedAt.current = Date.now();
+        camera.current?.controller?.setTorchMode('on').catch((error: unknown) => {


Start settling after the torch actually turns on

On Android devices where setTorchMode('on') takes most or all of the 500 ms window to complete, especially after a session restart, this starts the settle clock before the asynchronous request has lit the torch. As soon as controller.torchMode first becomes on, the elapsed time since the request may already exceed TORCH_SETTLE_MS, so a shutter press can take a snapshot before auto-exposure has had 500 ms under the new light; if the background upgrade fails or is claimed first, that underexposed snapshot is the submitted receipt. Start the settle interval when the torch is confirmed on (or after the setter fulfills), not before requesting it.

Useful? React with 👍 / 👎.

Fixed for the restart path: the settle clock now restarts when setTorchMode('on') resolves, and there’s a test for a slow torch. When flash is first turned on, the torch comes from the torchMode prop, which gives no signal for when it’s lit. I’m leaving that path as is: it needs a shutter press within about 500 ms of the torch lighting, and the photo upgrade usually replaces the snapshot.

marufsharifi · 2026-10-26T15:36:38Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified any copy / text that was added to the app is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
If the PR adds or modifies the UI:
- I asked an AI agent to review the changes for accessibility issues and addressed its findings.
- I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
- I verified all new/changed elements have meaningful accessible names and roles.
- I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Screen_Recording_20261027_183344_Expensify.Dev.mp4

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

joekaufmanexpensify

Good for product

marufsharifi

LGTM

mountiny

Thanks for this, looks good to me

mountiny · 2026-11-02T03:52:03Z

@OlimpiaZurek can you please resolve the conflicts?

# Conflicts: # src/pages/iou/request/step/IOURequestStepScan/components/Camera/index.native.tsx

OlimpiaZurek · 2026-11-02T08:27:53Z

@OlimpiaZurek can you please resolve the conflicts?

@mountiny done

mountiny

Nice, thank you

OSBotify · 2026-11-03T05:19:38Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

github-actions · 2026-11-03T05:27:05Z

🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here.

github-actions · 2026-11-03T05:31:27Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #104840 with the pinned Mobile-Expensify submodule.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-b0838b26-5b2e51a-841c36f21b93a602c8cbf7412ad5c85b6d94b7c2/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-b0838b26-5b2e51a-14b48957af50f4fcc33838137c5f04a1958d5bc1/index.html

Web 🕸️
https://104840.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

OSBotify · 2026-11-03T22:14:16Z

🚀 Deployed to staging by https://github.com/mountiny in version: 9.5.31-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	failure ❌
🍎 iOS 🍎	success ✅

MelvinBot · 2026-11-03T22:17:19Z

No help site update needed — the Android capture change is gated behind the scanFlashTorch beta and does not make existing article instructions incorrect.

OSBotify · 2026-11-03T22:30:18Z

🚀 Deployed to staging by https://github.com/mountiny in version: 9.5.31-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

OSBotify · 2026-11-04T20:25:04Z

🚀 Deployed to production by https://github.com/blimpich in version: 9.5.31-4 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

Android
iOS

Use the torch and a snapshot for Android flash scans

ea3dc84

melvin-bot Bot assigned OlimpiaZurek Oct 23, 2026

OlimpiaZurek mentioned this pull request Oct 23, 2026

[Due for payment 2026-11-11] [Metrics] ManualShutterToConfirmation - Investigate why Android spans are twice as slow as iOS #104482

Open

3 tasks

OlimpiaZurek added 2 commits October 26, 2026 13:16

fix:Turn the torch back on when the scan camera restarts

8bc8524

Merge branch 'main' into feat/android-flash-torch-snapshot

fe1d4b9

OlimpiaZurek marked this pull request as ready for review October 26, 2026 13:19

OlimpiaZurek requested review from a team as code owners October 26, 2026 13:19

melvin-bot Bot requested review from marufsharifi and removed request for a team October 26, 2026 13:19

melvin-bot Bot requested review from joekaufmanexpensify and removed request for a team October 26, 2026 13:19

chatgpt-codex-connector Bot reviewed Oct 26, 2026

View reviewed changes

fix:Start torch settle time when the relit torch is on

61a2182

joekaufmanexpensify previously approved these changes Oct 26, 2026

View reviewed changes

marufsharifi approved these changes Oct 30, 2026

View reviewed changes

melvin-bot Bot requested review from Julesssss and cristipaval October 30, 2026 06:55

Merge branch 'main' into feat/android-flash-torch-snapshot

e476db4

mountiny previously approved these changes Nov 2, 2026

View reviewed changes

Merge branch 'main' into feat/android-flash-torch-snapshot

57a1d7c

# Conflicts: # src/pages/iou/request/step/IOURequestStepScan/components/Camera/index.native.tsx

OlimpiaZurek dismissed mountiny’s stale review via 57a1d7c November 2, 2026 08:24

OlimpiaZurek dismissed joekaufmanexpensify’s stale review via 57a1d7c November 2, 2026 08:24

mountiny approved these changes Nov 3, 2026

View reviewed changes

mountiny merged commit b0838b2 into Expensify:main Nov 3, 2026
39 of 40 checks passed

OlimpiaZurek mentioned this pull request Nov 3, 2026

[Metrics] ManualShutterToConfirmation - Optimize "Confirm details" page rendering after receipt capture #83503

Open

OSBotify mentioned this pull request Nov 3, 2026

Deploy Checklist: New Expensify 2026-11-03 #105799

Closed

99 tasks done

		torchRequestedAt.current = Date.now();
		camera.current?.controller?.setTorchMode('on').catch((error: unknown) => {

Conversation

OlimpiaZurek commented Oct 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

codecov Bot commented Oct 23, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

OlimpiaZurek commented Oct 26, 2026

Uh oh!

OlimpiaZurek commented Oct 26, 2026

Uh oh!

chatgpt-codex-connector Bot commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codex Review Summary

Uh oh!

MelvinBot commented Oct 26, 2026

Review

1. The torch is not re-lit when the camera becomes active again

2. torchRequestedAt measures from the toggle, not from when the torch lit

3. Minor: torchMode='off' goes to devices without a torch

Uh oh!

melvin-bot Bot commented Oct 26, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

OlimpiaZurek Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

marufsharifi commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

joekaufmanexpensify left a comment

Choose a reason for hiding this comment

Uh oh!

marufsharifi left a comment

Choose a reason for hiding this comment

Uh oh!

mountiny left a comment

Choose a reason for hiding this comment

Uh oh!

mountiny commented Nov 2, 2026

Uh oh!

OlimpiaZurek commented Nov 2, 2026

Uh oh!

mountiny left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

OSBotify commented Nov 3, 2026

Uh oh!

github-actions Bot commented Nov 3, 2026

Uh oh!

github-actions Bot commented Nov 3, 2026

Uh oh!

OSBotify commented Nov 3, 2026

Uh oh!

MelvinBot commented Nov 3, 2026

Uh oh!

OSBotify commented Nov 3, 2026

Uh oh!

OSBotify commented Nov 4, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

OlimpiaZurek commented Oct 23, 2026 •

edited

Loading

codecov Bot commented Oct 23, 2026 •

edited by github-actions Bot

Loading

chatgpt-codex-connector Bot commented Oct 26, 2026 •

edited

Loading

2. `torchRequestedAt` measures from the toggle, not from when the torch lit

3. Minor: `torchMode='off'` goes to devices without a torch

marufsharifi commented Oct 26, 2026 •

edited

Loading