[google_maps_flutter] Fix A2A iOS builds#11290
[google_maps_flutter] Fix A2A iOS builds#11290stuartmorgan-g wants to merge 2 commits intoflutter:mainfrom
Conversation
Unshares `GoogleMapsUtilsTrampoline.h` and makes the `google_maps_flutter_ios` version, which only needs to support CocoaPods, unconditionally use the import version that CocoaPods needs. This works around the fact that (as discussed in the issue) we haven't yet found a way to reliably detect which mode this package is being built in that works in all the edge conditions we tested. `google_maps_flutter_ios_sdk*` will still be broken for A2A CocoaPods builds but: - Someone would have to explicitly opt into that, vs just try to use `google_maps_flutter`. - There is currently no advantage to using an `_sdk*` variant in a CocoaPods build. - Future versions of Flutter will support SwiftPM-based A2A flows. Given that, fixing this only for `google_maps_flutter` may be sufficient even in the long term, in addition to addressing the regression in the short term. Fixes flutter/flutter#183441
|
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. |
|
test-exempt: no behavioral change for anything but a specific A2A flow that is out of scope for testing in this repository |
There was a problem hiding this comment.
Code Review
This pull request addresses an issue with iOS add-to-app builds by modifying how GoogleMapsUtils is imported. The GoogleMapsUtilsTrampoline.h header is unshared, and the google_maps_flutter_ios package version is updated to unconditionally use the CocoaPods-style import (@import GoogleMapsUtils;). This is achieved by removing the conditional preprocessor logic from the header and also removing the corresponding FGM_USING_COCOAPODS definition from the podspec. The shared version of GoogleMapsUtilsTrampoline.h is deleted, and the file path is added to unshared_source_files.dart for google_maps_flutter_ios and its _sdk variants to make them responsible for their own versions. The package version for google_maps_flutter_ios is incremented to 2.18.1 and the CHANGELOG.md is updated accordingly.
Unshares
GoogleMapsUtilsTrampoline.hand makes thegoogle_maps_flutter_iosversion, which only needs to support CocoaPods, unconditionally use the import version that CocoaPods needs. This works around the fact that (as discussed in the issue) we haven't yet found a way to reliably detect which mode this package is being built in that works in all the edge conditions we tested.google_maps_flutter_ios_sdk*will still be broken for A2A CocoaPods builds but:google_maps_flutter._sdk*variant in a CocoaPods build.Given that, fixing this only for
google_maps_fluttermay be sufficient even in the long term, in addition to addressing the regression in the short term.Fixes flutter/flutter#183441
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