[MS-1544] Fixing issue with auto-capture. 'Start capture' now properly starts capturing

[alexandr-simprints]

JIRA ticket
Will be released in: 2026.3.0

Root cause analysis (for bugfixes only)

First known affected version: 2026.2.0
Start capture button does not start capturing until pressed for the second time.

start-capture-bug.mp4

Notable changes

• State management is fixed to consider the auto capture config

Testing guidance

• Describe how the reviewers can verify that issue is fixed

Additional work checklist

• Effect on other features and security has been considered
• Design document marked as "In development" (if applicable)
• External (Gitbook) and internal (Confluence) Documentation is up to date (or ticket created)
• Test cases in Testiny are up to date (or ticket created)
• Other teams notified about the changes (if applicable)

[Copilot]

Pull request overview

This PR addresses a regression in face auto-capture where tapping “Start capture” would not begin capturing until the second press, by adjusting how the UI/state machine treats the “auto-capture held off” period.

Changes:

• Exposes isAutoCaptureHeldOff from LiveFeedbackViewModel (read-only externally) so the UI can react to it.
• Updates LiveFeedbackFragment button feedback rendering to suppress guidance only while auto-capture is explicitly held off (instead of keying off phase != CAPTURING).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
face/capture/src/main/java/com/simprints/face/capture/screens/livefeedback/LiveFeedbackViewModel.kt	Makes isAutoCaptureHeldOff externally readable to support correct auto-capture start behavior.
face/capture/src/main/java/com/simprints/face/capture/screens/livefeedback/LiveFeedbackFragment.kt	Uses the held-off flag when deciding whether to show guidance on the capture button in auto-capture mode.

Suppressed comments (1)

face/capture/src/main/java/com/simprints/face/capture/screens/livefeedback/LiveFeedbackFragment.kt:318

• renderFeedbackOnButton now depends on vm.isAutoCaptureHeldOff, which is outside the LiveFeedbackState single-source-of-truth. This can lead to UI not re-rendering when only isAutoCaptureHeldOff changes (no state emission), and it breaks the stated deterministic rendering contract. Prefer carrying this flag in LiveFeedbackState (or exposing it as a Flow/StateFlow) and rendering purely from state.

        val feedback = if (state.isAutoCapture && vm.isAutoCaptureHeldOff) {
            LiveFeedbackState.Feedback.NONE
        } else {
            state.feedback
        }

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud