| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Bump Dart to 3.13, reformat, re-enable formatting check (#192649) Fixes https://github.com/flutter/flutter/issues/191628 Fixes https://github.com/flutter/flutter/issues/187204 Bumps Dart across the repo to 3.13 and reformats the repo The CI formatting check is also re-enabled with this change. #### Deviating pubspec.yaml Packages The following packages deviate from the standard repository Dart SDK constraint (^3.11.0-0 before the bump). Some of these cannot cleanly downgrade. Changing them is considered out of scope. Some of them may also pertain to active work that requires later versions of Dart. 1. ios_universal_link - Full File Path: dev/integration_tests/ios_universal_link/pubspec.yaml - Dart SDK Version: ^3.14.0-53.0.dev - Author: @okorohelijah - Commit: 2a071e20324 (2026-09-04) - PR / Message: Add iOS Universal Link integration test (Simulator) (#191443) 2. flutter_analyzer_plugin - Full File Path: dev/flutter_analyzer_plugin/pubspec.yaml - Dart SDK Version: ^3.7.0 - Author: @bkonyi - Commit: ae9963e8024 (2026-08-12) - PR / Message: [analysis] Reland "Added initial implementation of the flutter_analyzer_plugin (#175679)" (#191022) 3. widget_preview_scaffold - Full File Path: dev/integration_tests/widget_preview_scaffold/pubspec.yaml - Dart SDK Version: ^3.12.0 - Author: @polina-c - Commit: 3ca99c34868 (2026-05-15) - PR / Message: [ Widget Preview ] Improve zoom behavior and add zoom slider (#186422) 4. hybrid_platform_views - Full File Path: dev/integration_tests/hybrid_android_views/pubspec.yaml - Dart SDK Version: ^3.7.0-0 - Author: @andrewkolos - Commit: 112f1704d1e (2026-03-09) - PR / Message: Reland hybrid views test (#181336) 5. record_use_test_app - Full File Path: dev/integration_tests/record_use_test_app/pubspec.yaml - Dart SDK Version: >=3.5.0-0 <4.0.0 - Author: @dcharkes - Commit: eb6acab7f31 (2026-04-09) - PR / Message: [record_use] Add experimental flag and test project (#184719) 6. record_use_test_package - Full File Path: dev/integration_tests/record_use_test_package/pubspec.yaml - Dart SDK Version: >=3.5.0-0 <4.0.0 - Author: @dcharkes - Commit: eb6acab7f31 (2026-04-09) - PR / Message: [record_use] Add experimental flag and test project (#184719) 7. data_asset_app - Full File Path: dev/integration_tests/data_asset_app/pubspec.yaml - Dart SDK Version: >=3.5.0-0 <4.0.0 - Author: @dcharkes - Commit: a0924c76b0f (2026-04-07) - PR / Message: Reland "[data_assets] Cleanup tests" (#184714) 8. data_asset_package - Full File Path: dev/integration_tests/data_asset_package/pubspec.yaml - Dart SDK Version: >=3.5.0-0 <4.0.0 - Author: @dcharkes - Commit: a0924c76b0f (2026-04-07) - PR / Message: Reland "[data_assets] Cleanup tests" (#184714) ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant in-code documentation (doc comments with `///`). - [x] If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in [flutter/website] (or verified none is needed). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance. **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. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [AI contribution guidelines]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#ai-contribution-guidelines [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [flutter/website]: https://github.com/flutter/website [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md | 1 个月前 | |
[AGP 9] Add Unsupported AGP Version Functionality (#193609) Intentionally break builds that use unsupported (too new) AGP versions. This is in the event AGP releases a new AGP version we do not yet support. Fixes https://github.com/flutter/flutter/issues/193593 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant in-code documentation (doc comments with `///`). - [x] If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in [flutter/website] (or verified none is needed). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance. **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. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [AI contribution guidelines]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#ai-contribution-guidelines [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [flutter/website]: https://github.com/flutter/website [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md | 12 天前 | |
[ Tool ] Enable `omit_obvious_*_types` and `specify_nonobvious_*_types` lints (#172018) Sources under `packages/flutter_tools/` aren't accessible to the average Flutter user by navigating through sources from their projects, so it doesn't need to be as explicitly verbose with types for readability purposes. The `always_specify_types` lint results in extremely verbose code within the tool which adds little value. This change disables `always_specify_types` in favor of a new set of lints that aim to reduce verbosity by removing obvious types while also maintaining readability in cases where variable types otherwise wouldn't be obvious: - `omit_obvious_local_variable_types` - `omit_obvious_property_types` - `specify_nonobvious_local_variable_types` - `specify_nonobvious_property_types` | 1 年前 | |
`flutter build aar` regenerates tooling between each build-mode step (#162705) Closes https://github.com/flutter/flutter/issues/162703. I still need to do a similar change for `ios|macos`-`framework` in https://github.com/flutter/flutter/issues/162704. I added two unit tests, as well as opted in an integration test to the flag (it will become the default in https://github.com/flutter/flutter/pull/160289). /cc @reidbaker @gmackall. | 1 年前 | |
[flutter_tools] Guard socket streams and done futures against socket reset errors (#192941) When remote peers abruptly terminate or reset network connections, POSIX event handlers (such as epoll) trigger low-level socket reset errors (`SocketException: Error event raised in event handler : error condition has been reset, port = 0`) via `_NativeSocket.multiplex`. If these socket error events occur on streams or sink `done` futures that lack error handlers, or when adding to/closing sinks in an error state, the unhandled exception escapes into the Zone and causes Flutter tool crashes. This change: - Introduces `FutureErrorHandling<T>` in `packages/flutter_tools/lib/src/base/common.dart` to provide a reusable `.handleError(...)` extension on `Future` for background futures without requiring empty `(_) {}` callbacks. - Guards `createVmServiceDelegate` channel streams, sink `done` futures, and sink operations against `SocketException`. - Guards `DaemonStreams.fromSocket`, `DaemonStreams.connect`, and daemon server `socket.done` and `socket.addStream` futures. - Adds `onError` handling to `ProxiedPortForwarder` forwarded socket streams. - Adds `onError` handling to `ResidentRunner` log streams. - Adds error handling to `AndroidConsole` socket `done` future on connect and destroy. - Adds unit tests for `FutureErrorHandling.handleError` (including `test` predicate filtering) and regression tests verifying that socket stream and done future errors do not crash the tool. Fixes https://github.com/flutter/flutter/issues/192935 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing. | 16 天前 | |
[flutter_tools] Add TargetOperatingSystem and TargetPlatform.os (#193938) A lot of the code manually listed all the cpu architecture in `TargetPlatform` for a given OS only to check for the OS. Adding this simplifies those scenarios. | 6 天前 | |
[flutter_tools] Lazily initialize AndroidStudio validation and optimize candidate selection (#191968) ## Description This PR optimizes Android toolchain initialization by deferring expensive synchronous operations, candidate discovery, and SDK location scans out of tool startup. ### Why this is needed now As part of the modular dependency injection migration ([#190724](https://github.com/flutter/flutter/pull/190724)), context objects like `AndroidContext` are created upfront during `ToolDependencies.bootstrap` / runner initialization rather than via the old global ambient context (`AppContext`). Previously, `AndroidStudio` and `AndroidSdk` were initialized lazily only when a command or service queried `globals.androidStudio` or `context.get<AndroidStudio>()`. With upfront `AndroidContext` creation, `AndroidStudio.latestValid()` and `AndroidSdk.locateAndroidSdk()` ran on tool startup for every command. Because the constructors and locators performed synchronous filesystem scans and executed `java -version` (a JVM cold start), this introduced unnecessary latency to tool startup, including commands completely unrelated to Android (such as `flutter config` or iOS-specific workflows). ### Changes - Defers synchronous Java validation (`_initAndValidate()`) out of the `AndroidStudio` constructor so that object instantiation is fast and side-effect free. - `isValid`, `javaPath`, and `validationMessages` are evaluated lazily on first access. - In `AndroidStudio.latestValid()`, candidate installations are sorted in descending order of version prior to validation, allowing candidate discovery to short-circuit upon encountering the first valid installation without executing Java checks against older, unneeded candidates. - `AndroidContext` accepts lazy builder closures (`required AndroidSdk? Function() androidSdkBuilder`, `required AndroidStudio? Function() androidStudioBuilder`, `required GradleUtils Function() gradleUtilsBuilder`, and `required Java? Function() javaBuilder`) so commands that do not use Android do not pay any startup initialization cost. - `Java.find` accepts `required AndroidStudio? Function() androidStudioBuilder` builder closure so that creating the `Java` object does not eagerly trigger `AndroidStudio.latestValid()`. ## Related Issues Part of [#47161](https://github.com/flutter/flutter/issues/47161) (flutter_tools modular dependency injection migration). ## Tests - Updated `packages/flutter_tools/test/general.shard/android/android_studio_test.dart` to remove obsolete `FakeCommand` expectations for unneeded `java -version` executions. - Added unit tests verifying: - Constructor instantiation does not execute validation or touch the process manager. - `isValid`, `javaPath`, and `validationMessages` evaluate lazily on first access across independent instances. - `latestValid()` short-circuits candidate validation once a valid installation is found. - `latestValid()` falls back to older candidate installations when a newer installation is invalid. - Updated `packages/flutter_tools/test/general.shard/context/dependency_injection_test.dart` to verify: - `AndroidContext` lazily evaluates and memoizes `androidSdk`, `androidStudio`, `gradleUtils`, and `java`. - `AndroidContext` memoizes `null` results without re-evaluating builder closures. - `ToolDependencies.bootstrap` shares the same `AndroidStudio` instance across `AndroidContext` and `Java`. - `ToolDependencies.bootstrap` lazily evaluates `androidSdk` on first access rather than on startup. - Updated `packages/flutter_tools/test/general.shard/android/java_test.dart` to verify: - `Java.find` does not invoke the `androidStudioBuilder` factory if `jdk-dir` is configured. | 1 天前 | |
[flutter_tools] Lazily initialize AndroidStudio validation and optimize candidate selection (#191968) ## Description This PR optimizes Android toolchain initialization by deferring expensive synchronous operations, candidate discovery, and SDK location scans out of tool startup. ### Why this is needed now As part of the modular dependency injection migration ([#190724](https://github.com/flutter/flutter/pull/190724)), context objects like `AndroidContext` are created upfront during `ToolDependencies.bootstrap` / runner initialization rather than via the old global ambient context (`AppContext`). Previously, `AndroidStudio` and `AndroidSdk` were initialized lazily only when a command or service queried `globals.androidStudio` or `context.get<AndroidStudio>()`. With upfront `AndroidContext` creation, `AndroidStudio.latestValid()` and `AndroidSdk.locateAndroidSdk()` ran on tool startup for every command. Because the constructors and locators performed synchronous filesystem scans and executed `java -version` (a JVM cold start), this introduced unnecessary latency to tool startup, including commands completely unrelated to Android (such as `flutter config` or iOS-specific workflows). ### Changes - Defers synchronous Java validation (`_initAndValidate()`) out of the `AndroidStudio` constructor so that object instantiation is fast and side-effect free. - `isValid`, `javaPath`, and `validationMessages` are evaluated lazily on first access. - In `AndroidStudio.latestValid()`, candidate installations are sorted in descending order of version prior to validation, allowing candidate discovery to short-circuit upon encountering the first valid installation without executing Java checks against older, unneeded candidates. - `AndroidContext` accepts lazy builder closures (`required AndroidSdk? Function() androidSdkBuilder`, `required AndroidStudio? Function() androidStudioBuilder`, `required GradleUtils Function() gradleUtilsBuilder`, and `required Java? Function() javaBuilder`) so commands that do not use Android do not pay any startup initialization cost. - `Java.find` accepts `required AndroidStudio? Function() androidStudioBuilder` builder closure so that creating the `Java` object does not eagerly trigger `AndroidStudio.latestValid()`. ## Related Issues Part of [#47161](https://github.com/flutter/flutter/issues/47161) (flutter_tools modular dependency injection migration). ## Tests - Updated `packages/flutter_tools/test/general.shard/android/android_studio_test.dart` to remove obsolete `FakeCommand` expectations for unneeded `java -version` executions. - Added unit tests verifying: - Constructor instantiation does not execute validation or touch the process manager. - `isValid`, `javaPath`, and `validationMessages` evaluate lazily on first access across independent instances. - `latestValid()` short-circuits candidate validation once a valid installation is found. - `latestValid()` falls back to older candidate installations when a newer installation is invalid. - Updated `packages/flutter_tools/test/general.shard/context/dependency_injection_test.dart` to verify: - `AndroidContext` lazily evaluates and memoizes `androidSdk`, `androidStudio`, `gradleUtils`, and `java`. - `AndroidContext` memoizes `null` results without re-evaluating builder closures. - `ToolDependencies.bootstrap` shares the same `AndroidStudio` instance across `AndroidContext` and `Java`. - `ToolDependencies.bootstrap` lazily evaluates `androidSdk` on first access rather than on startup. - Updated `packages/flutter_tools/test/general.shard/android/java_test.dart` to verify: - `Java.find` does not invoke the `androidStudioBuilder` factory if `jdk-dir` is configured. | 1 天前 | |
[Android] Update the CLI to reject passing engine configuration flags with a prebuilt binary in release mode (#190870) > [!CAUTION] > This is a breaking change. Accompanying breaking change docs: https://github.com/flutter/website/pull/13796. For security purposes*, modifies the Flutter CLI to throw a fatal error **on Android only** when `flutter run --release --use-application-binary` is invoked **in addition to** passing any other Android engine configuration flags. So, for example, the following release-mode invocations for a Flutter Android app will be valid with this PR: - `flutter run --release` - `flutter run --release --verbose --enable-hcpp --any-other-engine-config-flag` - `flutter run --release --use-aplication-binary` The following will not be valid: - `flutter run --release --use-application-binary --verbose --enable-hcpp --any-other-android-engine-config-flag` *See https://github.com/flutter/flutter/issues/190461 for details. This is part of that work. ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance. **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. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [AI contribution guidelines]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#ai-contribution-guidelines [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Co-authored-by: Gray Mackall <34871572+gmackall@users.noreply.github.com> | 15 天前 | |
[flutter_tools] Migrate AndroidSdk and AndroidStudio away from globals (#193650) Migrates AndroidSdk and AndroidStudio away from globals.dart to explicit dependency injection via ToolContext. Part of https://github.com/flutter/flutter/issues/188471 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] All existing and new tests are passing. | 1 天前 | |
[flutter_tools] Migrate AndroidSdk and AndroidStudio away from globals (#193650) Migrates AndroidSdk and AndroidStudio away from globals.dart to explicit dependency injection via ToolContext. Part of https://github.com/flutter/flutter/issues/188471 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] All existing and new tests are passing. | 1 天前 | |
[flutter_tools] Lazily initialize AndroidStudio validation and optimize candidate selection (#191968) ## Description This PR optimizes Android toolchain initialization by deferring expensive synchronous operations, candidate discovery, and SDK location scans out of tool startup. ### Why this is needed now As part of the modular dependency injection migration ([#190724](https://github.com/flutter/flutter/pull/190724)), context objects like `AndroidContext` are created upfront during `ToolDependencies.bootstrap` / runner initialization rather than via the old global ambient context (`AppContext`). Previously, `AndroidStudio` and `AndroidSdk` were initialized lazily only when a command or service queried `globals.androidStudio` or `context.get<AndroidStudio>()`. With upfront `AndroidContext` creation, `AndroidStudio.latestValid()` and `AndroidSdk.locateAndroidSdk()` ran on tool startup for every command. Because the constructors and locators performed synchronous filesystem scans and executed `java -version` (a JVM cold start), this introduced unnecessary latency to tool startup, including commands completely unrelated to Android (such as `flutter config` or iOS-specific workflows). ### Changes - Defers synchronous Java validation (`_initAndValidate()`) out of the `AndroidStudio` constructor so that object instantiation is fast and side-effect free. - `isValid`, `javaPath`, and `validationMessages` are evaluated lazily on first access. - In `AndroidStudio.latestValid()`, candidate installations are sorted in descending order of version prior to validation, allowing candidate discovery to short-circuit upon encountering the first valid installation without executing Java checks against older, unneeded candidates. - `AndroidContext` accepts lazy builder closures (`required AndroidSdk? Function() androidSdkBuilder`, `required AndroidStudio? Function() androidStudioBuilder`, `required GradleUtils Function() gradleUtilsBuilder`, and `required Java? Function() javaBuilder`) so commands that do not use Android do not pay any startup initialization cost. - `Java.find` accepts `required AndroidStudio? Function() androidStudioBuilder` builder closure so that creating the `Java` object does not eagerly trigger `AndroidStudio.latestValid()`. ## Related Issues Part of [#47161](https://github.com/flutter/flutter/issues/47161) (flutter_tools modular dependency injection migration). ## Tests - Updated `packages/flutter_tools/test/general.shard/android/android_studio_test.dart` to remove obsolete `FakeCommand` expectations for unneeded `java -version` executions. - Added unit tests verifying: - Constructor instantiation does not execute validation or touch the process manager. - `isValid`, `javaPath`, and `validationMessages` evaluate lazily on first access across independent instances. - `latestValid()` short-circuits candidate validation once a valid installation is found. - `latestValid()` falls back to older candidate installations when a newer installation is invalid. - Updated `packages/flutter_tools/test/general.shard/context/dependency_injection_test.dart` to verify: - `AndroidContext` lazily evaluates and memoizes `androidSdk`, `androidStudio`, `gradleUtils`, and `java`. - `AndroidContext` memoizes `null` results without re-evaluating builder closures. - `ToolDependencies.bootstrap` shares the same `AndroidStudio` instance across `AndroidContext` and `Java`. - `ToolDependencies.bootstrap` lazily evaluates `androidSdk` on first access rather than on startup. - Updated `packages/flutter_tools/test/general.shard/android/java_test.dart` to verify: - `Java.find` does not invoke the `androidStudioBuilder` factory if `jdk-dir` is configured. | 1 天前 | |
Support activity-alias in Android launcher activity detection (#187251) Support activity-alias in Android launcher activity detection Fixes: #38965 ## Pre-launch Checklist - [X] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [X] I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools. - [X] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [X] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [X] I signed the [CLA]. - [X] I listed at least one issue that this PR fixes in the description above. - [X] I updated/added relevant documentation (doc comments with `///`). - [X] I added new tests to check the change I am making, or this PR is [test-exempt]. - [X] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [X] All existing and new tests are passing. | 1 个月前 | |
refactor(flutter_tools): clean up dead unreferenced declarations (#191163) Removes dead, unreferenced internal declarations across `packages/flutter_tools`. This is a **deterministic, tool-guided cleanup** performed using [`undead`](https://pub.dev/packages/undead) (whole-program AST reachability analysis). Because candidate declarations are identified through formal analyzer graph traversals rather than generative AI synthesis, there is **almost zero risk of AI hallucinations or speculative refactoring regressions**. --- ### 🔍 How `undead` Works & Non-Breaking Safety Guarantees Unlike basic lexical lints (`unused_element`, `unused_field`) which only detect file-private (`_`) identifiers within a single compilation unit, `undead` builds a comprehensive reachability graph starting from: 1. **Public API Entrypoints**: All exported root declarations in `lib/*.dart`. 2. **Executable Roots**: Binary/CLI command entrypoints. 3. **Test Suites**: Unit and integration test harnesses in `test/`. Any internal declaration under `lib/src/` with zero reachable paths from any entrypoint or test root is flagged as dead code. #### Verification & Non-Breaking Invariants * **Public API Preservation**: All public exports in `lib/` remain strictly untouched. * **Sealed Hierarchy Protection**: Subtypes of `sealed` classes are preserved to guarantee Dart 3 pattern-matching switch exhaustiveness. * **Framework Pragmas**: Entrypoints annotated with `@pragma('vm:entry-point')` are preserved. * **Regression Verification**: Verified clean via full `flutter_tools` static analysis (`dart analyze`) and passing local test suites (`dart test`) with zero behavioral drift. --- ### 📦 Removed Declarations Removes dead unreferenced declarations identified during the codebase reachability audit: - AndroidSdkNdkHelpers, kSupportedAbis, writeLocalProperties, conflictDetected - OverrideArtifacts, kSystemCodeSuccess, kSystemCodeDeviceFull - getNameForHostPlatform, getAotBuildDirectory, getFuchsiaBuildDirectory - kXcodeBuildScriptValueBuild, kXcodeBuildScriptValueEmbed, kXcodeBuildScriptValueAddToAppBuild - getNameForTargetPlatform, getTargetPlatformForName - verifyOutputDirectories, NoOpBuildTargets, _NoOpTarget - getDefaultApplicationKernelPath, DiscoveredApp, NoIdeValidator, ValidatorWithResult - flutterMacOSFrameworkDir, OSArchitectures, _osTargets, kLuciEnvName - loadDwdsDirectory, generateMethodArguments, L10nMissingPlaceholderException - HeaderGenerator, ConstructorGenerator, kExplicitlyExcludedPackages - generateDDCBootstrapScript, parseVersionForWindows, EdgeValidator - PreviewProperty, ParsedUnitResultExtension, SourceExtension, daemon id Also removed unused imports left behind by deletions. --- ### 🤖 Tool Provenance & Reproduction Dead code detection and reachability analysis performed with [`undead`](https://pub.dev/packages/undead) (`v0.1.0`). To reproduce or re-run this reachability audit locally: ```bash cd packages/flutter_tools && dart run undead@ ``` | 1 个月前 | |
[flutter_tools] Honor configured build-dir across flutter project and build targets (#191592) When `flutter config --build-dir=<out>` was set, `FlutterProject.buildDirectory`, `Environment.rootBuildDir`, and multiple build commands and targets still hardcoded the `'build'` string literal, causing the default `build/` directory to be created and populated alongside the custom build folder. This change: - Replaces hardcoded `'build'` with `getBuildDirectory()` in `FlutterProject.buildDirectory`, `Environment`, deferred components validators/targets, and framework build commands. - Makes `getBuildDirectory()` gracefully handle environments without injected context. - Adds regression tests in `project_test.dart`, `build_system_test.dart`, and `build_info_test.dart`. Fixes #102924 | 1 个月前 | |
[flutter_tools] Migrate gradle_errors and deferred_components_prebuild_validator away from globals (#193649) Migrates GradleErrorHandler and DeferredComponentsPrebuildValidator away from globals.dart to explicit dependency injection via ToolContext. Part of https://github.com/flutter/flutter/issues/188471 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] All existing and new tests are passing. | 1 天前 | |
[flutter_tools] Honor configured build-dir across flutter project and build targets (#191592) When `flutter config --build-dir=<out>` was set, `FlutterProject.buildDirectory`, `Environment.rootBuildDir`, and multiple build commands and targets still hardcoded the `'build'` string literal, causing the default `build/` directory to be created and populated alongside the custom build folder. This change: - Replaces hardcoded `'build'` with `getBuildDirectory()` in `FlutterProject.buildDirectory`, `Environment`, deferred components validators/targets, and framework build commands. - Makes `getBuildDirectory()` gracefully handle environments without injected context. - Adds regression tests in `project_test.dart`, `build_system_test.dart`, and `build_info_test.dart`. Fixes #102924 | 1 个月前 | |
feat(flutter_tools): extract AndroidGradleConfig and move toGradleConfig to AndroidBuildInfo (#194016) ### Rationale `BuildInfo` is the cross-platform build configuration passed across Android, iOS, Web, Desktop, and Fuchsia targets, yet it carried 6 loose Android/Gradle fields (`androidProjectArgs`, `androidGradleProjectCacheDir`, `androidGradleDaemon`, `androidSkipBuildDependencyValidation`, `androidEnableHcpp`, `explicitAndroidEnableHcpp`) and the Gradle `-P` flag serializer `toGradleConfig()`. Following #191018, #191510, #191760, #192307, #192455, #192524, #192818, and #193323, this change encapsulates those fields into `AndroidGradleConfig` and moves `toGradleConfig()` onto `AndroidBuildInfo` where all production callers already operate. ### Summary of Changes - Introduce `@immutable class AndroidGradleConfig` in `build_info.dart` and replace the 6 loose `android*` parameters on `BuildInfo` and `BuildInfo.copyWith` with `androidGradleConfig` (shrinking `BuildInfo`'s constructor from 28 to 23 parameters while preserving `AndroidDevice.startApp` forwarding during `flutter run`). - Move `toGradleConfig()` off `BuildInfo` onto `AndroidBuildInfo` (with zero `@deprecated` forwarders) and add `gradleDaemon` and `skipBuildDependencyValidation` convenience getters on `AndroidBuildInfo`. - Update `FlutterCommand.getBuildInfo()` in `flutter_command.dart` to construct `AndroidGradleConfig`. - Update `buildGradleApp`, `buildGradleAar`, and `_checkJavaAndGradleCompatibility` in `gradle.dart` to read Gradle configuration via `AndroidBuildInfo`. - Update unit tests across `build_info_test.dart`, `flutter_command_test.dart`, `android_gradle_builder_test.dart`, and `build_aar_test.dart`. ### Flow / Surface Delta ```mermaid flowchart LR A["FlutterCommand.getBuildInfo()"] --> B["BuildInfo(androidGradleConfig)"] B --> C["AndroidBuildInfo.toGradleConfig()"] C --> D["gradle.dart (-P flags)"] ``` ### Verification - Executed `dart analyze --fatal-infos` on `packages/flutter_tools` with 0 issues. - Executed `dart test` across `build_info_test.dart`, `flutter_command_test.dart`, `android_gradle_builder_test.dart`, and `build_aar_test.dart` (`160/160` passing). ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [ ] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing. | 1 天前 | |
[flutter_tools] Migrate gradle_errors and deferred_components_prebuild_validator away from globals (#193649) Migrates GradleErrorHandler and DeferredComponentsPrebuildValidator away from globals.dart to explicit dependency injection via ToolContext. Part of https://github.com/flutter/flutter/issues/188471 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] All existing and new tests are passing. | 1 天前 | |
Revert: Updated Most flutter/flutter Defaults to 37 (#193891) Reverts: [Updated Most flutter/flutter Defaults to 37](https://github.com/flutter/flutter/pull/193307) Initiated by: @jesswrd Reason for reverting: broke the tree Original PR Author: @jesswrd Reviewed By: @mboetger The original PR description is provided below: In this step, we generally update the compileSdk version to 37, the ndkVersion to a compatible version, and any test targets to API 37. We did not bump ndkVersion because the current version is already compatible here. There was also only one outstanding test target that needed to be bumped to API 37. Partially Addresses https://github.com/flutter/flutter/issues/189518 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant in-code documentation (doc comments with `///`). - [x] If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in [flutter/website] (or verified none is needed). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [ ] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance. **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. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [AI contribution guidelines]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#ai-contribution-guidelines [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [flutter/website]: https://github.com/flutter/website [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md | 9 天前 | |
[flutter_tools] Lazily initialize AndroidStudio validation and optimize candidate selection (#191968) ## Description This PR optimizes Android toolchain initialization by deferring expensive synchronous operations, candidate discovery, and SDK location scans out of tool startup. ### Why this is needed now As part of the modular dependency injection migration ([#190724](https://github.com/flutter/flutter/pull/190724)), context objects like `AndroidContext` are created upfront during `ToolDependencies.bootstrap` / runner initialization rather than via the old global ambient context (`AppContext`). Previously, `AndroidStudio` and `AndroidSdk` were initialized lazily only when a command or service queried `globals.androidStudio` or `context.get<AndroidStudio>()`. With upfront `AndroidContext` creation, `AndroidStudio.latestValid()` and `AndroidSdk.locateAndroidSdk()` ran on tool startup for every command. Because the constructors and locators performed synchronous filesystem scans and executed `java -version` (a JVM cold start), this introduced unnecessary latency to tool startup, including commands completely unrelated to Android (such as `flutter config` or iOS-specific workflows). ### Changes - Defers synchronous Java validation (`_initAndValidate()`) out of the `AndroidStudio` constructor so that object instantiation is fast and side-effect free. - `isValid`, `javaPath`, and `validationMessages` are evaluated lazily on first access. - In `AndroidStudio.latestValid()`, candidate installations are sorted in descending order of version prior to validation, allowing candidate discovery to short-circuit upon encountering the first valid installation without executing Java checks against older, unneeded candidates. - `AndroidContext` accepts lazy builder closures (`required AndroidSdk? Function() androidSdkBuilder`, `required AndroidStudio? Function() androidStudioBuilder`, `required GradleUtils Function() gradleUtilsBuilder`, and `required Java? Function() javaBuilder`) so commands that do not use Android do not pay any startup initialization cost. - `Java.find` accepts `required AndroidStudio? Function() androidStudioBuilder` builder closure so that creating the `Java` object does not eagerly trigger `AndroidStudio.latestValid()`. ## Related Issues Part of [#47161](https://github.com/flutter/flutter/issues/47161) (flutter_tools modular dependency injection migration). ## Tests - Updated `packages/flutter_tools/test/general.shard/android/android_studio_test.dart` to remove obsolete `FakeCommand` expectations for unneeded `java -version` executions. - Added unit tests verifying: - Constructor instantiation does not execute validation or touch the process manager. - `isValid`, `javaPath`, and `validationMessages` evaluate lazily on first access across independent instances. - `latestValid()` short-circuits candidate validation once a valid installation is found. - `latestValid()` falls back to older candidate installations when a newer installation is invalid. - Updated `packages/flutter_tools/test/general.shard/context/dependency_injection_test.dart` to verify: - `AndroidContext` lazily evaluates and memoizes `androidSdk`, `androidStudio`, `gradleUtils`, and `java`. - `AndroidContext` memoizes `null` results without re-evaluating builder closures. - `ToolDependencies.bootstrap` shares the same `AndroidStudio` instance across `AndroidContext` and `Java`. - `ToolDependencies.bootstrap` lazily evaluates `androidSdk` on first access rather than on startup. - Updated `packages/flutter_tools/test/general.shard/android/java_test.dart` to verify: - `Java.find` does not invoke the `androidStudioBuilder` factory if `jdk-dir` is configured. | 1 天前 |
Flutter Tools for Android
This section of the Flutter repository contains the command line developer tools for building Flutter applications on Android. What follows are some notes about updating this part of the tool.
Updating Android dependencies
The Android dependencies that Flutter uses to run on Android include the Android NDK and SDK versions, Gradle, the Kotlin Gradle Plugin, and the Android Gradle Plugin (AGP). The template versions of these dependencies can be found in gradle_utils.dart.
Follow the guides below when*...
Updating the template version of...
The Android SDK & NDK
All of the Android SDK/NDK versions noted in gradle_utils.dart
(compileSdkVersion, minSdkVersion, targetSdkVersion, ndkVersion)
versions should match the values in Flutter Gradle Plugin (FlutterExtension),
so updating any of these versions also requires an update in
FlutterExtension.
When updating the Android compileSdkVersion, minSdkVersion, or
targetSdkVersion, make sure that:
- Framework integration & benchmark tests are running with at least that SDK version.
- Flutter tools tests that perform String checks with the current template SDK versions are updated (you should see these fail if you do not fix them preemptively).
Also, make sure to also update to the same version in the following places:
- The versions for error/warn in
packages/flutter_tools/gradle/src/main/kotlin/DependencyVersionChecker.kt. - The version in the dependencies block in
packages/flutter_tools/gradle/build.gradle.kts. - The flutter min version in
engine/src/flutter/shell/platform/android/io/flutter/Build.java - The versions used when engine testing in
engine/src/flutter/shell/platform/android/test_runner/build.gradle - The versions used when working in engine/shell in
engine/src/flutter/shell/platform/android/build.gradle
Gradle
When updating the Gradle version used in project templates
(templateDefaultGradleVersion), make sure that:
- Framework integration & benchmark tests are running with at least this Gradle version.
- Flutter tools tests that perform String checks with the current template Gradle version are updated (you should see these fail if you do not fix them preemptively).
The Kotlin Gradle Plugin
When updating the Kotlin Gradle Plugin (KGP) version used in project templates
(templateKotlinGradlePluginVersion), make sure that the framework integration
& benchmark tests are running with at least this KGP version.
When updating the warnKGPVersion or errorKGPVersion ensure that versions used in
dev/tools/bin/generate_gradle_lockfiles.dart are updated if needed then regenerate
build.gradle(.kts) files.
For information about the latest version, check https://kotlinlang.org/docs/releases.html#release-details.
The Android Gradle Plugin (AGP)
When updating the Android Gradle Plugin (AGP) versions used in project templates
(templateAndroidGradlePluginVersion, templateAndroidGradlePluginVersionForModule),
make sure that:
- Framework integration & benchmark tests are running with at least this AGP version.
- Flutter tools tests that perform String checks with the current template AGP versions are updated (you should see these fail if you do not fix them preemptively).
A new version becomes available for...
Gradle
When new versions of Gradle become available, make sure to:
- Check if the maximum version of Gradle that we support
(
maxKnownAndSupportedGradleVersion) can be updated, and if so, take the necessary steps to ensure we are testing this version in CI. - Check that the Java version that is one higher than we currently support
(
oneMajorVersionHigherJavaVersion) based on current maximum supported Gradle version is up-to-date. - Update the
_javaGradleCompatListthat contains the Java/Gradle compatibility information known to the tool. - Update the test cases in gradle_utils_test.dart that test compatibility between Java and Gradle versions (relevant tests should fail if you do not fix them preemptively, but should also be marked inline).
- Update the test cases in create_test.dart that test for a warning for Java/Gradle incompatibilities as needed (relevant tests should fail if you do not fix them preemptively).
For more information about the latest version, check https://gradle.org/releases/.
The Android Gradle Plugin (AGP)
When new versions of the Android Gradle Plugin become available, make sure to:
- Update the maximum version of AGP that we know of (
maxKnownAgpVersion). - Check if the maximum version of AGP that we support
(
maxKnownAndSupportedAgpVersion) can be updated, and if so, take the necessary steps to ensure that we are testing this version in CI. - Update the
_javaAgpCompatListthat contains the Java/AGP compatibility information known to the tool. - Update the test cases in gradle_utils_test.dart that test compatibility between Java and AGP versions (relevant tests should fail if you do not fix them preemptively, but should also be marked inline).
- Update the test cases in create_test.dart that test for a warning for Java/AGP incompatibilities as needed (relevant tests should fail if you do not fix them preemptively).
- When Flutter adds support for a new AGP major version, bump
firstUnsupportedAGPMajorVersionin DependencyVersionChecker.kt so that builds using that major version are no longer blocked.
For information about the latest version, check https://developer.android.com/studio/releases/gradle-plugin#updating-gradle.
* There is an ongoing effort to reduce these steps; see https://github.com/flutter/flutter/issues/134780.