[google_maps_flutter] Add background color for unloaded tiles

[RyanHolanda]

Adds a nullable GoogleMap.backgroundColor option for configuring the color displayed behind map tiles while they are not fully loaded.

This prevents the native map surface from showing its default black background before tiles render. The value is forwarded during map initialization to:

• Android's GoogleMapOptions.backgroundColor.
• iOS's GMSMapViewOptions.backgroundColor in the default, SDK 9, and SDK 10 implementations.
• Web's JavaScript MapOptions.backgroundColor.

The existing SDK defaults remain unchanged when backgroundColor is null. Since the native options are initialization-time settings, changing the value after map creation has no effect.

No screenshots are included because this is an API-only platform integration change.

Fixes flutter/flutter#142520

Federated review note

This is the required combined-review PR for the federated plugin change. It intentionally contains repository-generated path dependency overrides marked DO NOT MERGE so the platform interface, implementations, and app-facing package can be reviewed and tested together.

The package publish dry-run passes for all seven packages. The federation safety check intentionally reports Unresolved combo PR, preventing this combined review branch from landing accidentally. Once the overall change is approved, it will be split and landed in dependency order:

1. Platform interface.
2. Android, iOS, and web implementations.
3. App-facing package after the preceding releases are published.

Test coverage

The change adds coverage for:

• App-facing configuration forwarding.
• Platform-interface diffing, equality, hashing, and legacy serialization.
• Android Dart-to-Pigeon conversion and native creation options.
• iOS Dart-to-Pigeon conversion and native GMSMapViewOptions creation across all maintained SDK implementations.
• Web conversion to the JavaScript map creation options, including alpha.

Local validation completed:

• Repository formatter: passed.
• Dart analysis and tests for all seven packages: passed.
• Android Gradle lint and native unit tests: passed.
• iOS SDK 9 and SDK 10 analysis and native tests: passed (72 tests each).
• iOS shared-source synchronization validator: passed.
• Web integration tests against the latest and minimum supported Flutter versions: passed.
• Package validation, license validation, and publish dry-runs: passed.

On the local Xcode 26.5 installation, the default CocoaPods native target is blocked before plugin tests by warnings promoted to errors in the third-party Google-Maps-iOS-Utils source. The identical shared implementation passes in the SDK 9 and SDK 10 targets; hosted CI will validate the repository's supported CocoaPods environment.

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. ↩ ↩²

[gemini-code-assist]

Code Review

This pull request introduces a backgroundColor option to GoogleMap to configure the color displayed behind unloaded map tiles. This change is implemented across the main package, the platform interface, and the Android, iOS, and Web platform implementations, along with corresponding tests. There are no review comments, and I have no feedback to provide.

[stuartmorgan-g]

Overall the structure looks good, thanks for the contribution!

Routing to platform teams for in-depth review of platform implementations before the PR is split apart.

[stuartmorgan-g]

Prefer creating a local backgroundColor variable and using that, so that you can rely on compiler-enforced autopromotion instead of force-unwrapping.

[stuartmorgan-g]

Same.

[stuartmorgan-g]

Same notes here as for Android.