[camera_avfoundation] Return accurate values for lensType on iOS

[coltrane]

Currently, CameraDescription.lensType is always .unknown on iOS. This PR implements a mapping from the iOS native AVCaptureDevice.DeviceType to the existing CameraLensType values defined in camera_platform_interface, ensuring that an accurate value for lensType will now be returned for all camera devices that camera_avfoundation presently supports.

This PR is offered as a possible alternative to #7653, and #9959, in case those PRs have become stalled. I believe this accomplishes the same goals and aligns with the discussions there, and in related issues. This PR may also provide somewhat better test coverage.

Fixes flutter/flutter#174390

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, e.g. [shared_preferences]
• 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 below to indicate which test exemption this PR falls under[^1].
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[gemini-code-assist]

Code Review

This pull request implements mapping of native iOS camera device types (AVCaptureDevice.DeviceType) to the platform-agnostic CameraLensType. This is achieved by updating the Pigeon interface to include lens type information, modifying the native Swift code to perform the mapping, and adjusting the Dart implementation to use the new data. The changes include new unit tests for the mapping logic and refactoring of existing tests. I have one suggestion to improve the robustness of the native Swift code.

[gemini-code-assist]

For better forward-compatibility, it's recommended to use @unknown default instead of default when switching over non-frozen enums like AVCaptureDevice.DeviceType. This will cause the compiler to issue a warning if a new case is added in a future SDK version, reminding us to handle it explicitly. This pattern is already used for device.position in this same file.

Suggested change

	switch device.deviceType {
	case .builtInWideAngleCamera:
	lensType = .builtInWideAngleCamera
	case .builtInTelephotoCamera:
	lensType = .builtInTelephotoCamera
	case .builtInUltraWideCamera:
	lensType = .builtInUltraWideCamera
	default:
	lensType = .unknown
	}
	switch device.deviceType {
	case .builtInWideAngleCamera:
	lensType = .builtInWideAngleCamera
	case .builtInTelephotoCamera:
	lensType = .builtInTelephotoCamera
	case .builtInUltraWideCamera:
	lensType = .builtInUltraWideCamera
	@unknown default:
	lensType = .unknown
	}

[coltrane]

In general, I'd agree with this suggestion, but in this specific case I think it's better to leave the "old" style default in place. Switching to @unknown default would require naming each of the current 15 values here. That would include some deprecated values, and also some non-camera devices like microphones and depth sensors. This might be something for closer consideration in a later PR.

But I'd welcome other perspectives from the reviewers.

[coltrane]

From "Linux repo_checks"

[0:00] Running for packages/camera/camera...
  No version change.
  Found NEXT; validating next version in the CHANGELOG.
No version change found, but the change to this package could not be verified to be exempt
from version changes according to repository policy.
If this is a false positive, please comment in the PR to explain why the PR
is exempt, and add (or ask your reviewer to add) the "override: no versioning needed" label.

No CHANGELOG change found.
If this PR needs an exemption from the standard policy of listing all changes in the CHANGELOG,
comment in the PR to explain why the PR is exempt, and add (or ask your reviewer to add) the
"override: no changelog needed" label.
Otherwise, please add a NEXT entry in the CHANGELOG as described in the contributing guide.

The only change in packages/camera/camera is the dependency override for camera_avfoundation, which I added according to the instructions in the instructions for changing federated plugins.

If I understand correctly, we will remove the dependency override after reviews are complete, and then camera/camera will have no changes. For this reason, I believe it's exempt from the versioning and change log requirements.

[coltrane]

Hello code owners @bparrishMines @vashworth @hellohuanlin

I'm unsure of the protocol here, so I just wanted to follow up, and flag this as being ready for review, when time permits.

I've rebased a couple of times to keep up with new changes landing on main, and I will try to continue to do so. Currently it seems that some checks are failing due to issues unrelated to this PR. The only check failure caused by this PR is due to the dependency_override in camera/camera which I explained in my comment above.

Please let me know if there's anything I've missed, or if other actions are needed on my part. Thanks for all you do -- much appreciated.

[stuartmorgan-g]

The only change in packages/camera/camera is the dependency override for camera_avfoundation, which I added according to the instructions in the instructions for changing federated plugins.

If I understand correctly, we will remove the dependency override after reviews are complete, and then camera/camera will have no changes. For this reason, I believe it's exempt from the versioning and change log requirements.

Those instructions are for multi-package PRs; PRs that change only package don't need any overrides, so that change should be reverted.

[coltrane]

Those instructions are for multi-package PRs; PRs that change only package don't need any overrides, so that change should be reverted.

Thanks @stuartmorgan-g. I've reverted that override, squashed, and rebased on main.

[coltrane]

Looks like #7653 landed. I'll close this PR since it essentially duplicated #7653.