[camera_avfoundation] iOS: Fix crash when enableAudio == false by correcting guard condition

[juliendelarbre]

Summary

This PR fixes an iOS crash that occurs when using the camera plugin with enableAudio: false and no NSMicrophoneUsageDescription in Info.plist.

Root cause:
In DefaultCamera.setUpCaptureSessionForAudioIfNeeded(), the guard currently allows audio setup to proceed even when audio is disabled:

// current (buggy)
guard !mediaSettings.enableAudio || !isAudioSetup else { return }

This evaluates to true when enableAudio == false, so the audio setup runs regardless.

Fix: Require audio to be enabled and not already set up before proceeding:

// fixed
guard mediaSettings.enableAudio && !isAudioSetup else { return }

This aligns behavior with the intended logic (“don’t set up audio twice or when audio is disabled”) and prevents the crash path on iOS when the microphone usage description is absent.

• Affected file:
  camera_avfoundation/ios/camera_avfoundation/Sources/camera_avfoundation/DefaultCamera.swift

• Proposed correction commit:
  juliendelarbre@0635db4

• Related Flutter issue & discussion:
  flutter/flutter#174702 (comment)

---

Before / After

Before (buggy): audio setup runs when enableAudio == false, causing a crash on iOS if NSMicrophoneUsageDescription is missing.

After (fixed): audio setup is skipped when enableAudio == false; no crash, behavior matches API expectations.

---

Reproduction steps

1. Create a Flutter project targeting iOS.
2. Ensure ios/Runner/Info.plist does not contain NSMicrophoneUsageDescription.
3. Initialize CameraController with enableAudio: false.
4. Call startVideoRecording().
5. Observe crash (on current main); with this PR applied, no crash.

---

Linked Issues

Fixes flutter/flutter#174702

---

Documentation

No API changes; behavior now matches the documented intent. (Optional: add a short inline comment elaborating that audio setup is skipped when enableAudio == false.)

---

Pre-Review Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] page, which explains my responsibilities.
• I read and followed the [relevant style guides] and ran [the auto-formatter].
• I signed the [CLA].
• The title of the PR starts with the name of the package surrounded by square brackets
• I [linked to at least one issue that this PR fixes] in the description above.
• I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy], or I have commented below to indicate which [version change exemption] this PR falls under[^1].
• I updated CHANGELOG.md to add a description of the change, [following repository CHANGELOG style], or I have commented below to indicate which [CHANGELOG exemption] this PR falls under[^1].
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented above to indicate which [test exemption] this PR falls under.
• All existing and new tests are passing.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[gemini-code-assist]

Code Review

This pull request addresses a critical crash on iOS that occurs when the camera is used with enableAudio: false without the NSMicrophoneUsageDescription in Info.plist. The change corrects the logic in the guard statement within setUpCaptureSessionForAudioIfNeeded to ensure audio setup is only attempted when audio is explicitly enabled and has not already been configured. The fix is correct and directly resolves the reported issue by aligning the code's behavior with its intended logic.

[hellohuanlin]

can you add some tests so that it doesn't regress

[juliendelarbre]

@hellohuanlin, added some test.