[google_maps_flutter] Add MapColorScheme support to Android and iOS

[snaeji]

Description

Wires up MapColorScheme (light/dark/followSystem) to native APIs on Android and iOS. The platform interface and app-facing google_maps_flutter package already exposed this parameter (added in 2.16.0 for web), but the Android and iOS plugins silently ignored it.

• Android: GoogleMap.setMapColorScheme() is invoked with the matching MapColorScheme constant. Both creation-time and runtime updates (via interpretMapConfiguration) are supported.
• iOS: GMSMapView.overrideUserInterfaceStyle is set to UIUserInterfaceStyleLight / Dark / Unspecified — the documented API per the Google Maps SDK for iOS.

The change is mirrored across google_maps_flutter_ios, google_maps_flutter_ios_sdk9, google_maps_flutter_ios_sdk10, and google_maps_flutter_ios_shared_code via dart tool/sync_shared_files.dart.

The colorScheme doc comment in google_maps_flutter and google_maps_flutter_platform_interface is updated to reflect the new platform support (previously documented as "Web only").

Tests added:

• Android: Convert.toMapColorScheme JUnit tests for all three enum values; interpretMapConfiguration_handlesColorScheme dispatcher test mirroring _handlesStyle; Dart-side creation-params test asserting colorScheme flows through to the platform view.
• iOS: Parametrized Dart-side creation-params tests covering light, dark, followSystem, and null; matching tests propagated to sdk9 and sdk10 via the shared-code sync.

Fixes flutter/flutter#186737

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• 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 followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• 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¹.
• All existing and new tests are passing.

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-assist bot 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

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request implements colorScheme support for cloud-based maps styling brightness on Android and iOS, extending the existing web functionality. The updates span the platform interface, native platform implementations, and Pigeon message definitions. A review comment correctly identifies that the documentation for colorScheme should be updated to reflect that it can be modified after map creation on iOS, aligning the documentation with the new implementation.

[LongCatIsLooong]

The iOS implementation LGTM modulo https://github.com/flutter/packages/pull/11736/changes#r3270153752

[LongCatIsLooong]

I believe switch expressions / statements have to be exhaustive or it is gong to be a compile time error. The code isn't going to compile if there's an unhandled case. IOW the runtime error will never be reachable, unless you add a default case. But adding a new case to an existing enum should require a major version bump I think? So we don't really have to handle that at runtime.

[LongCatIsLooong]

Also this could just be an expression:

return switch (colorScheme) { 
  null => null,
  .light => .light,
  .dart => .dart,
  .followSystem => .followSystem,
};

[LongCatIsLooong]

Actually, why do we need 2 enums that represent the same thing? Can we just re-export one / making one of the an alias of the other? Then we don't need this since there's only one type under the hood.

[stuartmorgan-g]

I believe switch expressions / statements have to be exhaustive or it is gong to be a compile time error.

Switch expressions do, not arbitrary switch statements.

But adding a new case to an existing enum should require a major version bump I think?

We have not traditionally considered that to be a major version change. We may need to revisit that at some point as switch expressions become more common, but for now we don't (at least for platform interfaces).

So we don't really have to handle that at runtime.

We do, for the specific goal of not requiring breaking the platform interface all the time.

[stuartmorgan-g]

Actually, why do we need 2 enums that represent the same thing?

Because Pigeon definitions currently aren't allowed to import things from other files. And doing so in the case of an enum from another package would be extremely dangerous since it would allow for Dart code to change without the native side changing.