Updates the release step to use 3.41.
Part of https://github.com/flutter/flutter/blob/master/docs/ecosystem/release/Updating-Packages-repo-for-a-stable-release.md
Includes a fix for an out-of-band breakage in tool unit tests, where the behavior of pubspec editing appears to be that it now normalizes final whitespace, causing some overly-picky tests to fail. The tool now:
- does a better job generating test pubspecs that don't have a bunch of extra newlines, and
- ignores trailing whitespace in tests checking file contents that were failing.
also opts in go_router
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
Implements approach E.1b from [the design doc](https://flutter.dev/go/google-maps-spm-versioning) about SwiftPM support. The main changes are:
- Adds a new `google_maps_flutter_ios_shared_code` directory which has an exact copy of almost all of the code files from `google_maps_flutter_ios`.
- Adds a new `tool` directory to `google_maps_flutter_ios` (and the shared code, so that it stays in sync) with two command scripts:
- `run_tests.dart`, which is automatically run by existing repo tool logic, as part of the custom tests task. This validates that for every file in `google_maps_flutter_ios_shared_code`, the corresponding file in `google_maps_flutter_ios` is identical (modulo some expected package name differences in specific cases). It lists all the files checked, to allow for easy auditing in CI output or locally about what is being shared.
- `sync_shared_files.dart`, which is a helper script for local use that copies all files in the current package that have changes relative to their shared code counterparts, both to the shared copy and all other copies. This is to make the local development process less painful; for most changes, all someone has to do is work in one of the packages, and then run this script when they are done to sync those changes to all the other copies. It also logs any code files that aren't shared, to remind people adding files to take the step of adding those to the shared copy if they should be shared.
- Adds two new duplicates of `google_maps_flutter_ios`, `..._sdk9` and `..._sdk10'` which are direct copies of `google_maps_ios` with very minor changes:
- Anything based on the package name is changed/renamed
- The podspecs are narrowed to use the relevant dependency versions and have the correct min iOS version for that SDK
- Swift.package entries are added, making the packages SwiftPM-compatible
- The CHANGELOGs are cleared.
- The READMEs are updated to explain each package's role/behavior.
There are some minor supporting changes:
- The `google_maps_flutter_ios` README has been adjusted to reflect the new set of options.
- Obj-C code using the Google Maps Utils package has been updated to handle differences in the package name for Obj-C (adapted from https://github.com/flutter/packages/pull/8288). I created a trampoline header to deal with this difference rather than inline the `#if` and explanation in each file.
- Dart test code has been updated to use a non-shared trampoline header to localize the import diffs due to different package names to a tiny non-shared file. (We could switch this to using the file rewriting logic that I ended up having to add to `sync_shared_files.dart` later; I left it this way to minimize the number of files we have to do rewriting in, but I'm fine with either option.)
- The Pigeon configuration forces a specific package name instead of auto-determining it. Pigeon currently uses the package name as part of the channel name for each call, so doing this avoids tons of unnecessary diff in the generated files. (This does mean that the different implementation packages are all using the same channel names, but that should be safe since `flutter` should only allow one of the implementations to be registered.)
Once this lands and the new packages are published, I will do a follow-up PR to add a `google_maps_flutter` README discussion of how and why to use these new packages.
Mostly completes https://github.com/flutter/flutter/issues/146920
## Pre-Review Checklist
[^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.
As title
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
Since `pub downgrade` runs package resolution, failure in that step can simply mean that resolution has failed, rather than indicating a problem with the actual downgrade process. This adjusts the message to make it clear that it's a potential resolver failure, to aid in understanding failures.
Fixes https://github.com/flutter/flutter/issues/178815
issue: https://github.com/flutter/flutter/issues/176944
Add a batch Release Flag in the publish command.
The main branch will only publish packages that are opted out of batch release.
The release branch will only publish packages that are opted into batch release.
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
This re-lands the FFI-based implementation from https://github.com/flutter/packages/pull/9762, which was reverted in https://github.com/flutter/packages/pull/10517.
It contains the following changes (other than version and changelog updates):
- Requires Flutter 3.38.4, to pick up the fix for https://github.com/flutter/flutter/issues/178715
- Requires `objective_c` 9.2.1, to pick up the fixes for https://github.com/flutter/flutter/issues/178915 and https://github.com/dart-lang/native/issues/2824
Also makes necessary repo-level changes:
- Updates the tool's Flutter->Dart version mapping to recognize 3.38.4, to make that minimum work
- Update the release action to use 3.38.5, to avoid having publishing due to using an older version of Flutter than the package requires.
Fixes https://github.com/flutter/flutter/issues/111033
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
This fixes main branch part of https://github.com/flutter/flutter/issues/176433
The work left is adjusting cocoon to also run this check in release branch
The high level view of this pr.
1. Move ci_config.yaml and pending changelog parsing into thir own files and the parsed results are exposed as a getter method in RepositoryPackage so that it can be shared between branch_for_release, repo_package_info_check, and version_check
2. The format error of ci_config.yaml and changelog files are reported in repo_package_info_check. The other 2 assume they are correct formatted and throw directly if they are not.
3. update the version_check to be able to handle batch release package
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
as title. This is required due to our policy
context: https://github.com/flutter/flutter/issues/179033
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
Replaces the code that attempted to find the topmost presented view controller as the context for presenting a Safari view controller with a call to the new registrar API to get the Flutter view's controller.
Since it's now possible for there not to be a view controller, adds an exception for that case. This should only be possible in an add-to-app scenario where someone tries to show an in-app URL from a Flutter view that is not being displayed, which is an unlikely enough scenario that I'm not going to consider this a breaking change.
Fixes https://github.com/flutter/flutter/issues/174415
## Pre-Review Checklist
[^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.
Replaces the full build-and-analyze version of `pod lib lint` with the `--quick` version. This means that this step no longer does native code analysis (which `analyze` covers), so it no longer needs an exclusion list for packages with warnings.
As a result of this change, flutter/packages no longer has a dependency on the version of Flutter that was published to CocoaPods to facilitate podspec testing.
Fixes https://github.com/flutter/flutter/issues/178806
Makes the analysis options changes described in
https://github.com/flutter/flutter/issues/178827:
- Adding
[omit_obvious_local_variable_types](https://dart.dev/tools/linter-rules/omit_obvious_local_variable_types)
- Adding
[specify_nonobvious_local_variable_types](https://dart.dev/tools/linter-rules/specify_nonobvious_local_variable_types)
- Adding
[specify_nonobvious_property_types](https://dart.dev/tools/linter-rules/specify_nonobvious_property_types)
- Adding
[type_annotate_public_apis](https://dart.dev/tools/linter-rules/type_annotate_public_apis)
- Removing
[always_specify_types](https://dart.dev/tools/linter-rules/always_specify_types)
After those changes, makes the following repo-wide changes:
- `dart fix --apply` in all packages and in script/tool/
- `dart format` in all packages and in script/tool/
- `update-excerpts` repo tooling command to update excerpts based on the
changes to their sources
Also updates the min Flutter/Dart SDK version to 3.35/3.9 for the
following packages, to avoid `analyze` failures in the `N-2` legacy
analysis run due to what appears to be a 3.9 change in what the Dart
analyzer continues to be an obvious local type in loop iterations:
- go_router
- google_fonts
- google_identity_services_web
- google_maps_flutter_web
- local_auth_platform_interface
- metrics_center
- multicast_dns
- pigeon
- rfw
- shared_preferences
- two_dimensional_scrollables
- vector_graphics_compiler
- mustache_template
- path_parsing
Because this is causing a significant amount of format churn already, I
took this opportunity to update the repository tooling to a min Dart SDK
of 3.8 (the N-2 stable version, so the earliest version we need the
tooling to support) to pick up the new format style, so the amount of
automated formatter change is higher in script/tool/ than in the
packages.
This does contain two manual changes (other than the repo tooling min
version):
-
d700b45c7d
changes `dynamic` to `Object?` in a few places where `dynamic` caused
analyzer warnings under the new rule set.
- Updates the repo tooling to ignore `.dart_tool/` when looking for
unexpected local `analysis_options.yaml` files, to fix issues running
the repo tool's `analyze` command locally based on recent changes in
`dart` behavior.
This does not include any CHANGELOG or version updates; even though we
normally version any changes to production code, mass automated changes
like this aren't worth the churn of releasing. This includes changes to
lib/example/main.dart and to README.md excerpts; while the style changes
will be user-visible on pub.dev, it's fine for those changes to wait for
the next release of each package.
Part of https://github.com/flutter/flutter/issues/178827
Converts `path_provider_foundation` from a Flutter plugin to a Dart-only package using `ffigen` to call into Foundation directly.
Most of the Dart unit tests had to be converted to integration tests, although they are still conceptually unit tests (i.e., they still inject mocks for the platform calls). This is because unlike Pigeon, where the API layer being mocked uses Dart types, the FFI calls that we now mock use Obj-C types, and those don't exist outside of an actual app runtime, so the integration test driver is the only place they can be hosted. This is very similar to how most of our web plugin implementations are unit tested.
Fixes https://github.com/flutter/flutter/issues/111033
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
fixes https://github.com/flutter/flutter/issues/176425
To set up a batch release cron job for a package, one needs to make a copy of packages/.github/workflows/go_router_batch.yml, and change the name and cron schedule.
The cron job does the following:
1. trigger batch_release_pr.yaml with the input package
batch_release_pr:
1. check out repo
2. Run script/tool/lib/src/branch_for_batch_release_command.dart to create branches with all the changes
3. create pr request
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
Add kgp to plugins bulk update dependency tooling.
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
When updating the repo for the 3.38 release, I missed the step of updating the release script (it's in the documented steps already, I just missed that line this time). This is causing a `release` failure for packages that require 3.38.
Uses 3.38.1 rather than 3.38.0 because of the Dart version mistake in 3.38.0.
Added AGP tooling for bulk updating agp versions in examples plugins.
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
Updated the Gradle version formatting validation with a stricter regex. Previously passed on invalid versions.
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
This fixes two issues with the format command's language resolution handling:
- It was not running `pub get` in sub-packages, so for the rare case of sub-packages with different min versions than their enclosing package, format behavior was inconsistent, and incorrect in CI where the tree starts clean.
- It was not detecting stale resolution, which was annoying when formatting locally since it's not uncommon to have last run `pub get` for some package before the last min SDK bump for that package, causing local formatting to be incorrect. This was especially problematic when doing min SDK bumps for the entire repo after `stable` releases.
It also fixes the related problem that `fetch-deps` was not running `pub get` in sub-packages, which would have prevented the pigeon issue in CI, but not locally. Even with `format` fixed, we still want everything fetched in `fetch-deps`.
The parsing does depend on internal implementation details of Dart, but we don't expect those to change frequently, and if it does we can update the detection logic as necessary. The failure mode should either be to throw, which we'll catch during the roll, or to run `pub get` more than necessary, which would just be an optimization issue rather than a correctness issue.
Includes `pigeon` format changes, since now CI is enforcing the correct format instead of the incorrect format that was checked in.
Fixes https://github.com/flutter/flutter/issues/178072
Helps with https://github.com/flutter/flutter/issues/176853
## Pre-Review Checklist
[^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.
Changes the default branch used to find merge bases from `FETCH_HEAD` to `main`. We were arranging for it to be `main` in CI, and locally it was an unpredictable value, so just hard-coding to `main` is likely to give better behavior locally with no change to CI behavior.
Fixes https://github.com/flutter/flutter/issues/176738
When a namespace is declared without a "=" assignment, there should be an error. I think the test did not check that the ouput contains an error. Noticed this because I saw an extra stack trace when running a test.
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
Adds repo tool validation that every package has an auto-labeler rule.
Fixes issues it found:
- Two missing packages
- One package with a typo in its glob that prevented it from working
This is pure ci setup and should not change packages' behaviors in anyway, feel free to ignore if you are pinned as a result due to being the package owners
This PR introduced an optional ci_config.yaml in package root meant to collect package level settings https://github.com/flutter/flutter/issues/172244. As of now, it only contains the batch release opt in.
Also added repocheck for this yaml file's format check.
fixes https://github.com/flutter/flutter/issues/176435
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
For all packages that have not already done so:
- Ensure that the minimum iOS version is 13.
- Ensure that the minimum macOS version is 10.15.
- Ensure that the minimum Flutter SDK version in 3.35 for anything with changes from the above.
In https://github.com/flutter/packages/pull/9849 I did the iOS plugins that had conditional logic for iOS <13, but I forgot to follow up with updating the minimum for the plugins that didn't have conditional logic.
Because this changes min Dart SDKs, it causes autoformat changes. There are no actual code changes in this PR; all Dart file changes are purely the result of re-running `dart format`.
This does bump the versions, even though repo policy would allow skipping version bumps for only changing min requirements, just to avoid conflating all the changes here with future releases.
Part of https://github.com/flutter/flutter/issues/167735
Part of https://github.com/flutter/flutter/issues/167745
## Pre-Review Checklist
[^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.
Bumps com.google.ads.interactivemedia.v3:interactivemedia from 3.36.0 to 3.37.0.
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
In my trials so far, Jules struggles to run the repo tooling commands once it has moved into a target directory, because it frequently tries to use a root-relative path instead of an absolute path. To try to reduce that problem, this instructs the agent to explicitly create an alias so that the later commands that reference REPO_ROOT as a placeholder will, hopefully, be run exactly as written in the examples instead.
Also, to reduce unnecessary working directory confusion, switch to `dart pub get -C` instead of `cd` followed by `dart pub get` for initializing the tooling. (Also makes the same change to the tool README, because why not have humans run one command instead of three.)
Fixed all Gradle 9 deprecations in packages repo.
Fixes https://github.com/flutter/flutter/issues/173320
Partially Adresses https://github.com/flutter/flutter/issues/173318
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
Merged hardcoded compileSdkVersion instead of using `flutter.compileSdkVersion`. Reverting back to `flutter.compileSdkVersion`.
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
Standardize `sourceCompatibility and targetCompatibility on the `=` form of property assignment.
Part of https://github.com/flutter/flutter/issues/176065
## Pre-Review Checklist
[^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.
Standardizes dependencies in build.gradle files on using parentheses rather than space. Also standardizes these lines on `"` rather than `'` while touching them, since that also moves closer to Kotlin syntax.
This doesn't enforce this syntax via repo tool checks, since it's not critical (it just reduces future churn when switching to Kotlin), and eventually the switch to Kotlin will provide the enforcement.
It does fix a latent issue where test-only dependency changes that used the () syntax wouldn't have been recognized by the tool as test-only changes for changelog/version check purposes.
Part of https://github.com/flutter/flutter/issues/176065
## Pre-Review Checklist
[^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.
Standardizes namespace on the `=` form of property assignment, and updates the existing namespace check to require that version.
Also standardizes these lines on `"` rather than `'` while touching them.
Part of https://github.com/flutter/flutter/issues/176065
## Pre-Review Checklist
[^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.
When the version and CHANGELOG updates are missing, suggest the helpful `update-release-info` command.
Log showing this in action:
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8706431147753704257/+/u/Run_package_tests/CHANGELOG_and_version_validation/stdout
```
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.
If this PR is not exempt, you may update the version and CHANGELOG with the "update-release-info" command. Example:
$ dart run script/tool/bin/flutter_plugin_tools.dart update-release-info \
--version=minimal \
--base-branch=upstream/main \
--changelog="Description of the change."
```
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
Per guidance from legal on current preferred practice, remove "All rights reserved" from all LICENSE files and header blocks, and update the repo tool check accordingly.
The `mustache_template` package has been transferred to the `flutter.dev` publisher, so this imports it into our repository and updates it to follow repository conventions:
- Fix/suppress analysis warnings
- Some via `dart fix`, some manual
- Add repo-level metadata
- Update license check command to recognize this package
- Add a temporary code-excerpt exclusion
- Update pubspec.yaml metadata
- Bump version to 2.0.1 to release the changes
`mustache_template` was itself a fork by a Flutter team member of the third-party `mustache` package, so the import is into `third_party/packages/`, updating the repo license check to recognize the license of this package.
The original code is quite old, and as a result still used a lot of implicit dynamic typing. Some of that that has been addressed in this import, but the trickier aspects have been left for future work, as converting from implicit dynamic typing to specified types has the potential for runtime regressions. (It's possible that even the more minor changes made here will cause regressions that will need fast-follow, but all the tests still pass, and the manual `test/all.dart` tests do not have any failures that were not present before making changes to the imported code).
Issues filed for future follow-up work:
https://github.com/flutter/flutter/issues/174721https://github.com/flutter/flutter/issues/174722https://github.com/flutter/flutter/issues/174742
## Pre-Review Checklist
[^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.
Instead of checking every file on the filesystem in the repo directory when checking licenses, only check the checked-in files. This avoids the problem of having many, many false positives when running locally if example apps have been built, since many builds create git-ignored files (generated files, downloaded Pods, etc.) that aren't our source, and so don't need to (and don't) pass the check that they contain our license block.
Folds native code analysis commands into `analyze` to simplify the set of commands:
- `lint-android` is now `analyze --no-dart --android`
- `xcode-analyze --ios` is now `analyze --no-dart --ios`
- `xcode-analyze --macos` is now `analyze --no-dart --macos`
In practice `--no-dart` is mostly there for CI; Dart analysis is fast enough that for local plugin development the new expected use case would likely be `analyze --whateverplatorm`, and it will run analysis on all relevant code in the package.
Part of https://github.com/flutter/flutter/issues/173413
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
The package has been discontinued on pub.dev.
Context for removal:
- It was never fully launched (e.g., the version on pub didn't follow the standard release process).
- It has not been actively developed in more than a year, and has been subject to bitrot ([example](https://github.com/flutter/flutter/issues/121257)).
- There are currently no plans to re-staff the project in the foreseeable future in order to get it to a stable state.
Since it's a use-as-needed tool rather than something that applications actively depend on, and it has <100 downloads per month, we are not doing a deprecation period.
Until https://github.com/flutter/flutter/issues/172427 is resolved, `xcode-analyze` doesn't work as desired with SwiftPM enabled (it analyzes only the test code, not the plugin code). To avoid losing analysis coverage in the meantime, this disabled SwiftPM temporarily while running analysis.
This PR also updates `build-examples` to use the newer pubspec-based config option to set the SwiftPM flag state instead of setting global state, to avoid future issues where we are unintentionally bleeding flag changes across different tests, and to make local runs not impact developer machine state.
To unit test this functionality, this adds a new feature to the existing process mock system that allows running an arbitrary test callback at the ponit where a process is being run, which in this case allows reading the temporarily-modified pubspec contents at the right point in the command execution.
Fixes https://github.com/flutter/flutter/issues/171442
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
> [!IMPORTANT]
> **(DONE ✅ in https://github.com/flutter/flutter/pull/172384)**
> https://github.com/flutter/flutter/pull/169899 must be rolled into packages AND be in Flutter stable for this to land. I will try to cherry-pick this change into 3.32 stable once the 3.35 beta is cut.
> [!NOTE]
> Several files are not changed but simply formatted as a result of the bumped Flutter/Dart versions for `camera_android_camerax` that include https://github.com/flutter/flutter/pull/171703. I will comment on these files for clarity.
Re-lands https://github.com/flutter/packages/pull/9360.
Since timing for `Surface` requests cannot be guaranteed, request a new `Surface` from `SurfaceProducer.getSurface` each time a `Surface` is requested for rendering the camera preview to.
Fixes https://github.com/flutter/flutter/issues/155294.
Fixes https://github.com/flutter/flutter/issues/169506.
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). 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.
[^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.
