Powered by the new and amazing `unnecessary_ignore` lint.
We're not enabling this lint by default because being able to
temporarily use ignores that don't ignore anything is a powerful tool to
enable migrations. We should turn this lint on locally periodically,
though, and clean up all outdated ignores.
This auto-formats all *.dart files in the repository outside of the
`engine` subdirectory and enforces that these files stay formatted with
a presubmit check.
**Reviewers:** Please carefully review all the commits except for the
one titled "formatted". The "formatted" commit was auto-generated by
running `dev/tools/format.sh -a -f`. The other commits were hand-crafted
to prepare the repo for the formatting change. I recommend reviewing the
commits one-by-one via the "Commits" tab and avoiding Github's "Files
changed" tab as it will likely slow down your browser because of the
size of this PR.
---------
Co-authored-by: Kate Lovett <katelovett@google.com>
Co-authored-by: LongCatIsLooong <31859944+LongCatIsLooong@users.noreply.github.com>
This PR attempts to improve clarity of androids section of `flutter
doctor -v` output by providing explicit information about which JDK is
being used and how to configure a different one if needed.
### Before
```console
• Java binary at: /Users/user/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents/jbr/Contents/Home/bin/java
```
### After
1. When JDK is from Android Studio:
```console
• Java binary at: /Users/users/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents/jbr/Contents/Home/bin/java
This is the JDK bundled with latest Android Studio installation
To manually set a custom JDK path, use: `flutter config --jdk-dir="path/to/jdk"`
```
2. When JDK is from JAVA_HOME env variable:
```console
• Java binary at: /Users/user/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents/jbr/Contents/Home/bin/java
This JDK is specified by JAVA_HOME environment variable
To manually set a custom JDK path, use: `flutter config --jdk-dir="path/to/jdk"`
```
3. When path to JDK is set in flutter config:
```console
• Java binary at: /Users/user/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents/jbr/Contents/Home/bin/java
This JDK was found in system PATH
To change current JDK, run: `flutter config --jdk-dir="path/to/jdk"`
```
4. When java binary is found in PATH (as fallback)
```console
• Java binary at: /Users/user/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents/jbr/Contents/Home/bin/java
This JDK is specified in Flutter configuration
To manually set a custom JDK path, use: `flutter config --jdk-dir="path/to/jdk"`
```
### Motivation
I think it's described in
https://github.com/flutter/flutter/issues/153156#issuecomment-2336814991.
TLDR; many developers struggle with Java-related issues and more verbose
doctor's output will (presumably) improve DX in that part.
fixes#153156
## 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].
<!-- 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: Andrew Kolos <andrewrkolos@gmail.com>
Closes https://github.com/flutter/flutter/issues/158012.
This is (effectively) a user-facing NOP, which is exchanging an
on-by-default command-line argument (`--implicit-pubspec-resolution`)
for an off-by-default global feature flag
(`explicit-package-dependencies`). It matches the mental model better,
is less painstaking to maintain and feed throughout, and will be easier
to globally flip on/off in a future PR.
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
`DartDevelopmentServiceLauncher` was created to share the DDS launch
logic from flutter_tools with other Dart tooling.
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
This reverts commit 7cdc23b3e1bae2bc7bc2d1f34773eaa3629d4fcc.
The failure in the `native_assets_test` integration test on Windows was caused by the DevTools process not being shutdown by the `ColdRunner` when running the profile mode portion of the test. This resulted in the test being unable to clean up the project created by the test as DevTools was still holding onto a handle within the directory. This PR adds back the mistakenly removed DevTools shutdown logic in the `ColdRunner`.
Reverts: flutter/flutter#146593
Initiated by: zanderso
Reason for reverting: Consistently failing `Windows_android native_assets_android` as in https://ci.chromium.org/ui/p/flutter/builders/prod/Windows_android%20native_assets_android/2533/overview
Original PR Author: bkonyi
Reviewed By: {christopherfujino, kenzieschmoll}
This change reverts the following previous change:
This change is a major step towards moving away from shipping DDS via Pub.
The first component of this PR is the move away from importing package:dds to launch DDS. Instead, DDS is launched out of process using the `dart development-service` command shipped with the Dart SDK. This makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the removal of instances of DevTools being served manually by the flutter_tool, instead relying on DDS to serve DevTools. This will be consistent with how the standalone Dart VM serves DevTools, tying the DevTools lifecycle to a live DDS instance. This will allow for the removal of much of the logic needed to properly manage the lifecycle of the DevTools server in a future PR. Also, by serving DevTools from DDS, users will no longer need to forward a secondary port in remote workflows as DevTools will be available on the DDS port.
There's two remaining circumstances that will prevent us from removing DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory profiles
This PR also includes some refactoring around `DebuggingOptions` to reduce the number of debugging related arguments being passed as parameters adjacent to a `DebuggingOptions` instance.
This change is a major step towards moving away from shipping DDS via
Pub.
The first component of this PR is the move away from importing
package:dds to launch DDS. Instead, DDS is launched out of process using
the `dart development-service` command shipped with the Dart SDK. This
makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the
removal of instances of DevTools being served manually by the
flutter_tool, instead relying on DDS to serve DevTools. This will be
consistent with how the standalone Dart VM serves DevTools, tying the
DevTools lifecycle to a live DDS instance. This will allow for the
removal of much of the logic needed to properly manage the lifecycle of
the DevTools server in a future PR. Also, by serving DevTools from DDS,
users will no longer need to forward a secondary port in remote
workflows as DevTools will be available on the DDS port. This code is currently
commented out and will be enabled in a future PR.
There's two remaining circumstances that will prevent us from removing
DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory
profiles
This PR also includes some refactoring around `DebuggingOptions` to
reduce the number of debugging related arguments being passed as
parameters adjacent to a `DebuggingOptions` instance.
While exploring https://github.com/flutter/flutter/issues/107607, I noticed that flutter_tools test results change based on whether `dart test` is run from a terminal or from a process (such as a Dart program). I also ran into this while writing tests for https://github.com/flutter/flutter/pull/150667.
This is due to tests that rely on the global `Stdio` instance, on which the `hasTerminal` property depends on whether the tool is being invoked from a terminal.
Ideally, `testUsingContext` would require any tests that depend on `globals.stdio` to define an override for `Stdio`, but this is not the case. Until a solution to this more general problem is figured out, I think we should have `testUsingContext` always provide a `Stdio` override by default.
This PR adds initial support for Swift Package Manager (SPM). Users must opt in. Only compatible with Xcode 15+.
Fixes https://github.com/flutter/flutter/issues/146369.
## Included Features
This PR includes the following features:
* Enabling SPM via config
`flutter config --enable-swift-package-manager`
* Disabling SPM via config (will disable for all projects)
`flutter config --no-enable-swift-package-manager`
* Disabling SPM via pubspec.yaml (will disable for the specific project)
```
flutter:
disable-swift-package-manager: true
```
* Migrating existing apps to add SPM integration if using a Flutter plugin with a Package.swift
* Generates a Swift Package (named `FlutterGeneratedPluginSwiftPackage`) that handles Flutter SPM-compatible plugin dependencies. Generated package is added to the Xcode project.
* Error parsing of common errors that may occur due to using CocoaPods and Swift Package Manager together
* Tool will print warnings when using all Swift Package plugins and encourage you to remove CocoaPods
This PR also converts `integration_test` and `integration_test_macos` plugins to be both Swift Packages and CocoaPod Pods.
## How it Works
The Flutter CLI will generate a Swift Package called `FlutterGeneratedPluginSwiftPackage`, which will have local dependencies on all Swift Package compatible Flutter plugins.
The `FlutterGeneratedPluginSwiftPackage` package will be added to the Xcode project via altering of the `project.pbxproj`.
In addition, a "Pre-action" script will be added via altering of the `Runner.xcscheme`. This script will invoke the flutter tool to copy the Flutter/FlutterMacOS framework to the `BUILT_PRODUCTS_DIR` directory before the build starts. This is needed because plugins need to be linked to the Flutter framework and fortunately Swift Package Manager automatically uses `BUILT_PRODUCTS_DIR` as a framework search path.
CocoaPods will continue to run and be used to support non-Swift Package compatible Flutter plugins.
## Not Included Features
It does not include the following (will be added in future PRs):
* Create plugin template
* Create app template
* Add-to-App integration
Fixes https://github.com/flutter/flutter/issues/130277
This PR does two things:
1. introduce a hidden `flutter build _preview` command, that will build a debug windows desktop app and copy it into the SDK's binary cache. This command is only intended to be run during packaging.
2. introduce a new device type, called `PreviewDevice`, which relies on the prebuilt desktop debug app from step 1, copies it into the target app's assets build folder, and then hot reloads their dart code into it.
Part of:
- https://github.com/flutter/flutter/issues/128251
Currently, when we want to use the analytics instance from `package:unified_analytics`, we are just grabbing it from globals. However, with the legacy analytics instance, there are some things we check to return a no-op version of the instance.. for example, if we are running on bots or a non standard branch, we use a no-op instance
This PR uses the same previous checks for the new analytics instance
Support for FFI calls with `@Native external` functions through Native assets on MacOS and iOS. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for MacOS and iOS.
Dylibs are bundled by (1) making them fat binaries if multiple architectures are targeted, (2) code signing these, and (3) copying them to the frameworks folder. These steps are done manual rather than via CocoaPods. CocoaPods would have done the same steps, but (a) needs the dylibs to be there before the `xcodebuild` invocation (we could trick it, by having a minimal dylib in the place and replace it during the build process, that works), and (b) can't deal with having no dylibs to be bundled (we'd have to bundle a dummy dylib or include some dummy C code in the build file).
The dylibs are build as a new target inside flutter assemble, as that is the moment we know what build-mode and architecture to target.
The mapping from asset id to dylib-path is passed in to every kernel compilation path. The interesting case is hot-restart where the initial kernel file is compiled by the "inner" flutter assemble, while after hot restart the "outer" flutter run compiled kernel file is pushed to the device. Both kernel files need to contain the mapping. The "inner" flutter assemble gets its mapping from the NativeAssets target which builds the native assets. The "outer" flutter run get its mapping from a dry-run invocation. Since this hot restart can be used for multiple target devices (`flutter run -d all`) it contains the mapping for all known targets.
### Example vs template
The PR includes a new template that uses the new native assets in a package and has an app importing that. Separate discussion in: https://github.com/flutter/flutter/issues/131209.
### Tests
This PR adds new tests to cover the various use cases.
* dev/devicelab/bin/tasks/native_assets_ios.dart
* Runs an example app with native assets in all build modes, doing hot reload and hot restart in debug mode.
* dev/devicelab/bin/tasks/native_assets_ios_simulator.dart
* Runs an example app with native assets, doing hot reload and hot restart.
* packages/flutter_tools/test/integration.shard/native_assets_test.dart
* Runs (incl hot reload/hot restart), builds, builds frameworks for iOS, MacOS and flutter-tester.
* packages/flutter_tools/test/general.shard/build_system/targets/native_assets_test.dart
* Unit tests the new Target in the backend.
* packages/flutter_tools/test/general.shard/ios/native_assets_test.dart
* packages/flutter_tools/test/general.shard/macos/native_assets_test.dart
* Unit tests the native assets being packaged on a iOS/MacOS build.
It also extends various existing tests:
* dev/devicelab/bin/tasks/module_test_ios.dart
* Exercises the add2app scenario.
* packages/flutter_tools/test/general.shard/features_test.dart
* Unit test the new feature flag.
Fixes https://github.com/flutter/flutter/issues/112833
Most of the actual changes here are in [packages/flutter_tools/lib/src/version.dart](https://github.com/flutter/flutter/pull/124558/files#diff-092e00109d9e1589fbc7c6de750e29a6ae512b2dd44e85d60028953561201605), while the rest is largely just addressing changes to the constructor of `FlutterVersion` which now has different dependencies.
This change makes `FlutterVersion` an interface with two concrete implementations:
1. `_FlutterVersionGit` which is mostly the previous implementation, and
2. `_FlutterVersionFromFile` which will read a new `.version.json` file from the root of the repo
The [`FlutterVersion` constructor](https://github.com/flutter/flutter/pull/124558/files#diff-092e00109d9e1589fbc7c6de750e29a6ae512b2dd44e85d60028953561201605R70) is now a factory that first checks if `.version.json` exists, and if so returns an instance of `_FlutterVersionFromGit` else it returns the fallback `_FlutterVersionGit` which will end up writing `.version.json` so that we don't need to re-calculate the version on the next invocation.
`.version.json` will be deleted in the bash/batch entrypoints any time we need to rebuild he tool (this will usually be because the user did `flutter upgrade` or `flutter channel`, or manually changed the commit with git).
Fixes#124252, finishing work on the umbrella tracking issue, #126126.
Essentially, after this PR, no (non-test) code should be be referencing/invoking the java home or binary paths.
## How we determine the channel name
Historically, we used the current branch's upstream to figure out the current channel name. I have no idea why. I traced it back to https://github.com/flutter/flutter/pull/446/files where @abarth implement this and I reviewed that PR and left no comment on it at the time.
I think this is confusing. You can be on a branch and it tells you that your channel is different. That seems weird.
This PR changes the logic to uses the current branch as the channel name.
## How we display channels
The main reason this PR exists is to add channel descriptions to the `flutter channel` list:
```
ianh@burmese:~/dev/flutter/packages/flutter_tools$ flutter channel
Flutter channels:
master (tip of tree, for contributors)
main (tip of tree, follows master channel)
beta (updated monthly, recommended for experienced users)
stable (updated quarterly, for new users and for production app releases)
* foo_bar
Currently not on an official channel.
ianh@burmese:~/dev/flutter/packages/flutter_tools$
```
## Other changes
I made a few other changes while I was at it:
* If you're not on an official channel, we used to imply `--show-all`, but now we don't, we just show the official channels plus yours. This avoids flooding the screen in the case the user is on a weird channel and just wants to know what channel they're on.
* I made the tool more consistent about how it handles unofficial branches. Now it's always `[user branch]`.
* I slightly adjusted how unknown versions are rendered so it's clearer the version is unknown rather than just having the word "Unknown" floating in the output without context.
* Simplified some of the code.
* Made some of the tests more strict (checking all output rather than just some aspects of it).
* Changed the MockFlutterVersion to implement the FlutterVersion API more strictly.
* I made sure we escape the output to `.metadata` to avoid potential injection bugs (previously we just inlined the version and channel name verbatim with no escaping, which is super sketchy).
* Tweaked the help text for the `downgrade` command to be clearer.
* Removed some misleading text in some error messages.
* Made the `.metadata` generator consistent with the template file.
* Removed some obsolete code to do with the `dev` branch.
## Reviewer notes
I'm worried that there are implications to some of these changes that I am not aware of, so please don't assume I know what I'm doing when reviewing this code. :-)
Reverts flutter/flutter#126086.
This PR changed the interfaces of some classes, namely `AndroidSdk`, and deleted a global.
These classes had custom overrides in g3 that were not updated with a g3fix, so this PR has broken tests. See https://b.corp.google.com/issues/281945232 (non-public link)
This is the first step in unifying Java-finding logic across the tool. If curious, see #126029 for an example of what all the changes will probably entail.
Moves java-related functionality like `AndroidSdk.findJavaHome` to a new class, `Java`.
See tracking issue https://github.com/flutter/flutter/issues/126126 for more.
https://github.com/flutter/flutter/issues/123917
Doc covering a broad set of issues related to android studio updating.
https://docs.google.com/document/d/1hTXkjbUrBnXgu8NQsth1c3aEqo77rWoEj8CcsQ39wwQ/edit?pli=1#
Specifically this pr:
- Adds new functions to find a projects AGP, Gradle and java versions,
and tests.
- Adds new functions that take versions and parse if the versions are
compatible with each other, and tests.
- Adds validator for `flutter analyze --suggestions` that evaluates the
java/gradle/agp versions and checks if they are compatible, and
integration test.
- Updates the version of gradle used by
dev/integration_tests/flutter_gallery/ to the minimum supported by java
18 so that the integration tests pass (It is unknown why the java
version is 18.9 instead of 11)
- Moves `isWithinVersionRange` to version.dart, and tests.
- Adds FakeAndroidStudio to fakes to be used in multiple tests but does
not remove existing copies.
Metrics will be included as part of the definition of done for this bug
but not as part of this cl. It is already too big.
Known work still left in this pr:
* Understand why analyze integration tests are failing.
Example output if Java and gradle are not compatible:
```
┌───────────────────────────────────────────────────────────────────┐
│ General Info │
│ [✓] App Name: espresso_example │
│ [✓] Supported Platforms: android │
│ [✓] Is Flutter Package: yes │
│ [✓] Uses Material Design: yes │
│ [✓] Is Plugin: no │
│ [✗] Java/Gradle/Android Gradle Plugin: │
│ │
│ Incompatible Java/Gradle versions. │
│ │
│ Java Version: 17.0.6, Gradle Version: 7.0.2 │
│ │
│ See the link below for more information. │
│ https://docs.gradle.org/current/userguide/compatibility.html#java │
│ │
└───────────────────────────────────────────────────────────────────┘
```
Example output if Gradle and AGP are not compatible
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ General Info │
│ [✓] App Name: espresso_example │
│ [✓] Supported Platforms: android │
│ [✓] Is Flutter Package: yes │
│ [✓] Uses Material Design: yes │
│ [✓] Is Plugin: no │
│ [✗] Java/Gradle/Android Gradle Plugin: Incompatible Gradle/AGP versions. │
│ │
│ Gradle Version: 7.0.2, AGP Version: 7.4.2 │
│ │
│ Update gradle to at least "7.5". │
│ See the link below for more information: │
│ https://developer.android.com/studio/releases/gradle-plugin#updating-gradle │
│ │
│ Incompatible Java/Gradle versions. │
│ │
│ Java Version: 17.0.6, Gradle Version: 7.0.2 │
│ │
│ See the link below for more information: │
│ https://docs.gradle.org/current/userguide/compatibility.html#java │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
```
Example output if Java/Gradle/Agp are not compatible.
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ General Info │
│ [✓] App Name: espresso_example │
│ [✓] Supported Platforms: android │
│ [✓] Is Flutter Package: yes │
│ [✓] Uses Material Design: yes │
│ [✓] Is Plugin: no │
│ [✗] Java/Gradle/Android Gradle Plugin: Incompatible Gradle/AGP versions. │
│ │
│ Gradle Version: 7.0.2, AGP Version: 7.4.2 │
│ │
│ Update gradle to at least "7.5". │
│ See the link below for more information: │
│ https://developer.android.com/studio/releases/gradle-plugin#updating-gradle │
│ │
│ Incompatible Java/Gradle versions. │
│ │
│ Java Version: 17.0.6, Gradle Version: 7.0.2 │
│ │
│ See the link below for more information: │
│ https://docs.gradle.org/current/userguide/compatibility.html#java │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
```
Commit messages
- Add function to gradle_utils.dart that gets the gradle version from
wrapper or system and add a test for each situation
- Add method to get agp version, add method to validate agp against
gradle version, update documentation, add tests for agp validation.
- Update dart doc for validateGradleAndAgp to describe where the info
came from and corner case behavior, create function to validate java and
gradle and hardcode return to false
- Fill out and test java gradle compatibility function in gradle_utils
- Hook up java gradle evaluateion to hasValidJavaGradleAgpVersions with
hardcoded java version
- Add java --version output parsing and tests
- Add getJavaBinary test
- Update comment in android_sdk for mac behavior with java_home -v
## 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].
- [ ] All existing and new tests are passing.
Fuchsia will soon remove all support for Component Framework version 1
components (recognized by component manifests ending in `.cmx`).
Notably, some of the `flutter` tool commands for Fuchsia devices--
notably, but not limited to, those related to CFv1--are outdated, and
either do not work today or soon won't work.
This PR removes the outdated components and commands, replacing some
with the newer version, or simply removing the non-working features,
in some cases.
