This change allows for users to open an instance of the DevTools Widget
Inspector within a web view embedded in the widget previewer. This will
allow for developers to inspect their previews without requiring IDEs to
create a special debug session for the widget previewer application.
DWDS is also rolled as part of this change to add DDS and DevTools
support for the `web-server` device.
Fixes https://github.com/flutter/flutter/issues/166423
**Demo:**
https://github.com/user-attachments/assets/3e3a1098-0526-4c7f-8087-38fb84f28335
Refactoring of code in `package:dwds` `26.2.1` changed execution
ordering enough for a race condition in the web benchmark harness to be
hit. This change updates the web benchmark harness to not rely on
waiting for console output from the spawned browser which can be missed.
Fixes https://github.com/flutter/flutter/issues/178326
---------
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Instead of generating assembly code that is then compiled to a Mach-O
dynamic library, use the new app-aot-macho-dylib output option for
gen_snapshot to generate the Mach-O dynamic library without the assembly
step.
This is a reland of https://github.com/flutter/flutter/pull/171626, with
the necessary changes to avoid the issue found in
https://github.com/flutter/flutter/issues/174393 where DWARF information
was being retained in the final snapshot. The initial PR state are the
original commits landed in the previous PR, with a followup commit
containing the fix for that issue: the DWARF information is moved into
an associated relocatable object, so the information is still accessible
by dsymutil before the snapshot is stripped.
Related issues:
* https://github.com/dart-lang/sdk/issues/43299
* https://github.com/dart-lang/sdk/issues/60307
## 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.
Before this change, there was logic in `flutter attach` that would try
and listen for a new application to attach to in the scenario the
current target application disappeared. This behavior isn't documented,
and has resulted in a `StateError` being thrown due to the VM service
URIs stream being listened to multiple times.
This change removes this behavior, which also prevents the `StateError`
from being thrown.
Fixes https://github.com/flutter/flutter/issues/156692, which is a
top-10 crasher for the tool.
This change fixes an issue where the preview command would crash if a
`pubspec.yaml` was added / deleted somewhere under the previewed
directory. It also improves testing for `PreviewManifest` in the context
of pub workspaces and ensures that `FlutterProject` instances are
refreshed based on the latest `pubspec.yaml` contents.
Fixes https://github.com/flutter/flutter/issues/179155
---------
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
To ensure build hooks emit code assets that are compatible with the main
app, Flutter tools pass a `CCompilerConfig` toolchain configuration
object to hooks. This is generally what we want, hooks on macOS should
use the same `clang` from XCode as the one used to compile the app and
native Flutter plugins for instance.
In some cases however, we need to run hooks without necessarily
compiling a full Flutter app with native sources. A good example for
this is `flutter test`, which runs unit / widget tests in a regular Dart
VM without embedding it in a Flutter application. So since `flutter
test` wouldn't invoke a native compiler, running build hooks shouldn't
fail if the expected toolchain is missing.
Currently however, `flutter test` tries to resolve a compiler toolchain
for the host platform. Doing that on Windows already allows not passing
a `CCompilerConfig` if VSCode wasn't found, but on macOS and Linux, this
crashes. This fixes the issue by allowing those methods to return `null`
instead of throwing. They still throw by default, but for the test
target they are configured to not pass a toolchain to hooks if none
could be resolved. This means that hooks not invoking the provided
toolchain (say because they're only downloading native artifacts
instead) would now work, whereas previously `flutter test` would crash
if no toolchian was found.
This closes https://github.com/flutter/flutter/issues/178715 (but only
the part shared in the original issue description, @dcharkes suggested
fixing a similar issue in the same PR but that is _not_ done here).
Since `flutter clean` can delete the `.dart_tool/` directory while a
`flutter widget-preview start` command is active, it's possible for the
`widget_preview_scaffold` to be deleted and cause the preview process to
crash.
This change works around this issue by always generating the
`widget_preview_scaffold` project under $TMP on each invocation of the
previewer. This doesn't result in much of a regression in startup times
as we currently aren't launching the previewer using restored state as
this isn't currently possible with the web device targets. Moving the
scaffold under $TMP means Flutter tooling will never accidentally delete
the scaffold while the previewer is running.
Filed https://github.com/flutter/flutter/issues/179036 to track
reverting this behavior when a better solution is found.
Fixes https://github.com/flutter/flutter/issues/175058
<!--
Thanks for filing a pull request!
Reviewers are typically assigned within a week of filing a request.
To learn more about code review, see our documentation on Tree Hygiene:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
-->
Passes `EXCLUDED_ARCHS` from Xcode project build settings to the
xcodebuild command, fixing macOS builds when
dependencies don't support all architectures.
### Problem
Release builds for macOS create universal binaries (arm64 + x86_64) by
default. This causes build failures when
using native dependencies that only provide binaries for a single
architecture. While developers can set
`EXCLUDED_ARCHS` in their Xcode project's xcconfig files, Swift Package
Manager dependencies don't respect this
project-level setting.
**Fixes**: https://github.com/flutter/flutter/issues/176605
## Solution
Instead of adding a CLI flag, pass `EXCLUDED_ARCHS` from the Xcode
project's build settings directly to xcodebuild. This ensures Swift
Package Manager dependencies respect architecture exclusions set in the
project configuration.
**How it works:**
When `macos/Runner/Configs/Release.xcconfig` contains:
```xcconfig
EXCLUDED_ARCHS = x86_64
```
The build command now includes `EXCLUDED_ARCHS=x86_64`, creating an
arm64-only binary.
## Usage
**1. Edit your xcconfig file** (e.g.,
`macos/Runner/Configs/Release.xcconfig`):
```xcconfig
#include "../../Flutter/Flutter-Release.xcconfig"
#include "Warnings.xcconfig"
// Exclude x86_64 for dependencies that only support Apple Silicon
EXCLUDED_ARCHS = x86_64
```
**2. Build normally:**
```bash
flutter build macos --release
```
**Without exclusions (default behavior):**
```bash
# Creates universal binary (arm64 + x86_64)
flutter build macos --release
```
## Implementation
- Modified `buildMacOS()` to retrieve `EXCLUDED_ARCHS` from Xcode
project build settings
- Pass `EXCLUDED_ARCHS` to xcodebuild command when set and non-empty
- Removed unused `activeArch` parameter
- Added inline documentation explaining the SPM compatibility fix
## Testing
**Manual verification:**
- ✅ Built ExecuTorch Flutter example with `EXCLUDED_ARCHS = x86_64`:
arm64-only binary (518.6MB)
- ✅ Built without exclusions: universal binary (existing behavior)
- ✅ Verified architecture with `lipo -info`: arm64-only when excluded
**Unit tests:**
- ✅ Added test: "Passes EXCLUDED_ARCHS from Xcode project to xcodebuild
command"
- ✅ Added test: "Does not pass EXCLUDED_ARCHS when not set in Xcode
project"
- ✅ All 25 macOS build tests passing
*If you had to change anything in the [flutter/tests] repo, include a
link to the migration guide as per the [breaking change policy].*
## 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.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
**Note**: The Flutter team is currently trialing the use of [Gemini Code
Assist for
GitHub](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
[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: Victoria Ashworth <15619084+vashworth@users.noreply.github.com>
FlutterBuildSystem.trackSharedBuildDirectory stores a hash of the most
recently run build configuration in the output directory defined in the
environment.
If the build executed by FlutterHookRunnerNative uses the same output
directory as other builds, then trackSharedBuildDirectory may think that
the hook build's output list replaces the outputs of those previous
builds. trackSharedBuildDirectory will then incorrectly delete files in
the previous output list because they are not part of the hook build's
outputs.
See https://github.com/flutter/flutter/issues/178529
Move getFinalTargetUri to ProxyRule class
Fix doc comments
Pares URI immediately when creating RegexProxyRule
---------
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
(Please be generous for some typos and grammar error in sentences below.
English is not my mother tongue)
TRDR : This patch fixes flutter run(and might be flutter build too)
failure on iOS flutter apps with companion watchOS app in case the
WKCompanionAppBundleIdentifier value is defined by xcode project
configuration and uses different app bundle id by scheme(which happens
when you do something like com.myapp.app1.dev things for scheme bundle
id)
This change checks default scheme (the scheme with corresponding name
for the debug/release mode and selected build flavor.) in the build
settings check step of containsWatchCompanion function.
current code of containsWatchCompanion function works like below
1. check all default Info.plist file's content of all targets to
determine if the project has watchOS companion apps.
(this doesn't work well in mordern xcode settings when they use multi
plist files which are selected on build time by build configuration.
Sometimes, the default Info.plist file doesn't even exist in the
project.)
2. check if "WKCompanionAppBundleIdentifier" is included in the xcode
project info file(the ios/Runner.xcodeproj/project.pbxproj file in case
of iOS project generated by flutter)
3. If "WKCompanionAppBundleIdentifier" has found in the project info
file,
check build configuration variables of every single scheme but the
current target scheme if they have config value with key
"INFOPLIST_KEY_WKCompanionAppBundleIdentifier" identical to current
build configuration's bundle identifier returned by
productBundleIdentifier@xcode_project.dart function.
I believe The third step causes many problems reported in some issue and
pr, saying iOS app with companion watchOS app fails on build or run.
https://github.com/flutter/flutter/issues/160622https://github.com/flutter/flutter/pull/172436
In my case, My iOS project had multiple schemes which are linked to
different build configurations, but using single Runner setting per app.
because we exclude current scheme for the check, we get all the
INFOPLIST_KEY_WKCompanionAppBundleIdentifier values except the one which
should be same with the identifier returned by
productBundleIdentifier@xcode_project.dart function.
that is because companion watch apps doesn't have to have same
WKCompanionAppBundleIdentifier with other scheme's main app. We have to
check the default scheme to see watchOS companion app`s
WKCompanionAppBundleIdentifier, not other scheme. (other schemes can
have slightly different or totally different bundle id. that was to
support different environment systems like dev, prod in my case)
as a result, flutter run gave me WatchOS app built for device target
iOS/iPad, not Watch. which caused problem during installation of iOS app
to a simulator because the embeded Watch App was in invalid format. I
found this by inspecting Info.plist of generated watchOS app.
below is part of the flutter run verbose log with failure caused by old
code.
[+1154 ms] An error was encountered processing the command
(domain=IXUserPresentableErrorDomain, code=1):
App installation failed: ‘Bora Debug-dev’을(를) 설치할 수 없음 (which says
"cannot install" in korean)
나중에 다시 시도하십시오. (which says "try again later" in korean)
Found WatchKit 2.0 app at
/Users/javalia/Library/Developer/CoreSimulator/Devices/071691B3-7901-47E5-9B38-4D5B799F3530/data/Library/Caches/com.apple.mobile.installd.staging/temp.8HZIEG/extracted/Payload/Runner.app/Watch/bora
Watch App.app but it does not have a WKWatchKitApp or WKApplication key
set to true in its Info.plist
Underlying error (domain=IXUserPresentableErrorDomain, code=1):
‘Bora Debug-dev’을(를) 설치할 수 없음 (which says "cannot install" in korean)
나중에 다시 시도하십시오. (which says "try it later" in korean)
I suggest this change with two reasons :
1. I think forcing watchOS app makers split their runner configurations
to support watch companion app is something not recommendable/not good
to force as a convention.
(Which is implied in the comment which is removed by this pr, and could
be one of the valid detouring.
some people in this issue
https://github.com/flutter/flutter/issues/160622 said that a detouring
is adding of dummy WKCompanionAppBundleIdentifier configuration in iOS
app, which should be in only watchOS apps in normal.)
2. The function should work as it's name implies, so I guess it should
not omit default scheme during check. Matching function's behavior with
it's name will be likely to reduce potential errors caused by this
change while fixing problems.
## 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.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [ ] 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].
**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
[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: hellohuanlin <41930132+hellohuanlin@users.noreply.github.com>
If the `.dart_tool/widget_preview_scaffold/.dart_tool/` directory wasn't
created during the initial run of `flutter widget-preview start` due to
the command being interrupted or `pub` being disabled, `flutter
widget-preview start` would crash due to the `package_config.json` logic
walking up the directory structure looking for the nearest
`package_config.json`. This would point to the parent project's
`package_config.json`, which would not be compatible with the widget
preview scaffold project.
Fixes https://github.com/flutter/flutter/issues/178660 and
https://github.com/flutter/flutter/issues/177655
It's possible that the preview detector is in the middle of processing
sources after a source file was changed while the widget previewer is
shutting down if we're not holding the mutex. This can result in the
analysis context being disposed of when we don't expect it, causing
requests to the analyzer to return errors.
This change guards against this scenario by ensuring that all calls to
`findPreviewFunctions` are guarded by the mutex. This change also
removes assumptions related to the return type from analyzer APIs to
account for the possibility that an error response was returned.
Fixes https://github.com/flutter/flutter/issues/178472
If Flutter Web is not enabled, the widget previewer will crash when
trying to find a web device to launch with. This change explicitly
checks for this case and throws `ToolExit` with instructions to enable
Flutter Web if it's not enabled.
Fixes https://github.com/flutter/flutter/issues/178486
## Summary
When running `flutter build ipa` with a project that uses manual code
signing (`CODE_SIGN_STYLE=Manual`) for Release/Profile, the tool
currently prints:
```
Automatically signing iOS for device deployment using specified development team in Xcode project: x
```
This is misleading in two ways:
1. The project is not using automatic signing for Release/Profile, it's
explicitly using manual signing with a provisioning profile.
2. The build in this mode is typically for App Store/TestFlight
distribution, not just device deployment.
Users who rely on manual signing (for example, Push Notifications + Sign
in with Apple entitlements) often hit an `xcodebuild -exportArchive`
failure later (`"Runner.app" requires a provisioning profile ...`) and
assume Flutter overrode their signing, because of this log line. This
confusion has been reported in the context of `flutter build ipa` where
archive succeeds but export fails, and Flutter's messaging doesn't match
the actual signing setup.
**Related issues:**
- #106612 - Support `flutter build ipa` with manual signing and
provisioning profiles
- #113977 - Flutter build IPA with --export-options-plist not working
## What this change does
* Before logging "Automatically signing iOS ...", we now check the
active build configuration's `CODE_SIGN_STYLE`.
* If the style is `Manual`, we suppress the automatic-signing message
(since manual signing is not automatic).
* If the style is `Automatic` or not set, we keep the original behavior.
* No functional behavior of signing or export is changed.
## Before
```
Automatically signing iOS for device deployment using specified development team in Xcode project: x
```
(This message appears even when `CODE_SIGN_STYLE=Manual`)
## After
```
(No message when CODE_SIGN_STYLE=Manual, since signing is not automatic)
```
(The message only appears when `CODE_SIGN_STYLE=Automatic` or not set)
## Tests
* Added test in
`packages/flutter_tools/test/general.shard/ios/code_signing_test.dart`
to assert we don't emit the automatic-signing message when
`CODE_SIGN_STYLE=Manual`.
* All existing tests pass (40/40 tests in code_signing_test.dart).
## Why this helps
* Reduces confusion around manual signing / App Store export flows.
* Matches expectations from users who configure provisioning profiles
manually and expect Flutter to respect that configuration.
* Prevents users from thinking Flutter is overriding their manual
signing setup based on misleading log output.
## Breaking Changes
None. This change only affects log output and does not modify any
signing behavior, export behavior, or CLI interface.
## Verification
Reviewers can verify this fix by:
1. Creating a test iOS project with `CODE_SIGN_STYLE=Manual` and
`DEVELOPMENT_TEAM` set in Xcode project settings
2. Running `flutter build ipa --release --verbose`
3. Confirming the log does NOT show "Automatically signing iOS..."
4. Verifying the app still builds/signs correctly
The included unit test covers this scenario automatically.
---
Supersedes #177851 (that PR accidentally included unrelated commits from
my fork history). This version only includes the intended change and
tests.
---------
Co-authored-by: Navaron Bracke <brackenavaron@gmail.com>
The `flutter` tool creates various directories for ephemeral state while
executing commands. In some situations, these directories contain or
link to other Dart / Flutter projects with '.dart' sources or
'pubspec.yaml's. If these files change while the widget previewer is
active (e.g., due to a `flutter pub get` downloading and configuring new
plugins for the project), the previewer's directory watcher will detect
the change and attempt to analyze the source. This causes an exception
to be thrown by the analyzer as the modified file path does not have a
valid analysis context.
This change adds additional checks to the `PreviewDetector` that allow
for ignoring changes to `pubspec.yaml`s and `.dart` sources under known
ephemeral directories (e.g., build/,
linux/flutter/ephemeral/, etc), as well as `.dart` files that aren't
associated with an analysis context.
Fixes https://github.com/flutter/flutter/issues/178317
## Description
This PR introduces platform-specific asset support in `pubspec.yaml`.
Currently, Flutter does not allow specifying which platforms an asset
should be included for.
This results in all declared assets being bundled for every target
platform, even if some are irrelevant (e.g. desktop-only or mobile-only
images).
### What this PR changes
- Adds a new optional `platforms` field under each asset in
`pubspec.yaml`.
- The field accepts a list of strings (platform identifiers, e.g.
`["android", "ios", "web", "windows", "macos", "linux"]`).
- Assets with a `platforms` restriction are only included in the bundle
when building for a matching platform.
- Invalid values (non-strings or unknown platform names) log an error.
### Example
```yaml
flutter:
assets:
- path: assets/logo.png
- path: assets/web_worker.js
platforms: [web]
- path: assets/desktop_icon.png
platforms: [windows, linux, macos]
```
#### Before
All assets (`logo.png`, `web_worker.js`, `desktop_icon.png`) are bundled
into **every build**, regardless of platform.
#### After
- `logo.png` is included on all platforms.
- `web_worker.js` is included only on web builds.
- `desktop_icon.png` is included only on desktop builds.
### Why this is useful
This significantly improves bundle size, prevents unused resources from
being shipped, and gives developers better control over asset
management.
## Issues
Fixes#65065
## Reviewer note
Would a design document be helpful for this change, or is the current
explanation sufficient?
## 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.
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[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
Using the presence of `.dart_tool` in a project to determine if it's a
valid Flutter project is not correct as the directory will not exist if
`flutter pub get` has not yet been run.
Fixes https://github.com/flutter/flutter/issues/178052
With the addition of IDE support, the widget previewer is often started
by default by IDE plugins, even if users don't open the previewer. This
change adds an additional analytics event which is reported once the
widget preview application is loaded and connects to the DTD instance.
Fixes https://github.com/flutter/flutter/issues/177948
