Conversation
camsim99
commented
Sep 30, 2026
|
|
||
| ## Proposed solution | ||
|
|
||
| Keep `torchEnabled` as the **requested** torch mode, which is how the app sees it: `CameraValue.flashMode` stays `torch` across `setDescription`. Then **apply that request again every time the plugin gets a new CameraX `Camera`**, skipping cameras that have no flash unit. Reset the request on `dispose`, because a new `CameraController` starts from default settings. |
Contributor
Author
There was a problem hiding this comment.
Sometimes there is more than a front/back camera. Should we consider saving a mapping of the camera to the torch state to account for this versus a single bool?
| ## Open questions | ||
|
|
||
| > [!IMPORTANT] | ||
| > **1. Expected behavior.** The report says "after step 4, the torch does not turn back **off**". I've assumed you meant "**on**", because you expect it to come back on and keep its state from step 2. Is that right? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Continuation of #12302..
Restores the state of a camera when that camera was previously initialized. For example, if you initialize camera A and start the torch, then initialize camera B, then switch back to A, the torch will turn off when camera B is started but then turn back on when switching back to camera A.
Fixes flutter/flutter#160956.
Normal pull request information above the line.
This pull request is an attempt to "oneshot" fixing flutter/flutter#160956. Using antigravity to execute a plan that is collaboratively worked on. The "rules" are to not allow human authored code to camera_android_camerax and to not rely on human code review feedback for code iteration.
We can add documentation, skills, mcp servers, presubmit test etc. Basically any "support infrastructure" for development is allowed but the package changes must be generated as a single pass.
When we discover that the plan is not good enough we will blow the package changes away and either modify the plan or add more support infrastructure and try again.
The implementation plan used to create this PR can be found at commit: 2e222ee
For more information see the project proposal doc go/flutter-project-one-shot or the working doc for this specific attempt go/flutter-project-one-shot-torch.
Pre-Review Checklist
[shared_preferences]///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2