PR provides a new option to the `test` command to include coverage info of specified packages.
It helps collecting coverage info in test setups where test code lives in separate packages or for multi-package projects.
At present, only current package is included to the final report.
Usage:
Consider an app with two packages: `app`, `common`.
Some of the tests in `app` use (indirectly) code that is located in `common`. When running with `--coverage` flag, that code is not included in the coverage report by default. To include `common` package in report, we can run:
```sh
flutter test --coverage --coverage-package app --coverage-package common
```
Note that `--coverage-package` accepts regular expression.
Fixes https://github.com/flutter/flutter/issues/79661
Fixes https://github.com/flutter/flutter/issues/101486
Fixes https://github.com/flutter/flutter/issues/93619
Fixed types for `_getNewServiceWorker` and `_waitForServiceWorkerActivation` functions.
These functions currently expect a Promise as an argument, but we're actually passing in an already resolved value:
```js
.then(this._getNewServiceWorker)
.then(this._waitForServiceWorkerActivation);
```
This migrator will upgrade the minSdkVersion used in the [module-level build.gradle](https://developer.android.com/build#module-level) file to flutter.minSdkVersion.
The PR also makes a small refactor to `AndroidProject` to add a getter for the module level build.gradle file, and uses that getter in places where we were getting that file (previously it was being gotten directly via `hostAppGradleRoot.childDirectory('app').childFile('build.gradle')`.
Part of the work for deprecating support for the Jelly Bean android apis.
Closes https://github.com/flutter/flutter/issues/80013.
**Before**:
```
$ flutter create test1 --description "a: b"
Creating project test1...
Error detected in pubspec.yaml:
Error on line 2, column 15: Mapping values are not allowed here. Did you miss a colon earlier?
â·
2 â description: a: b
â ^
âµ
Please correct the pubspec.yaml file at /Users/matan/Developer/scratch/test1/pubspec.yaml
```
**After**:
```
$ flutter create test1 --description "a: b"
Creating project test1...
Resolving dependencies in test1...
Got dependencies in test1.
Wrote 129 files.
All done!
You can find general documentation for Flutter at: https://docs.flutter.dev/
Detailed API documentation is available at: https://api.flutter.dev/
If you prefer video documentation, consider: https://www.youtube.com/c/flutterdev
In order to run your application, type:
$ cd test1
$ flutter run
Your application code is in test1/lib/main.dart.
```
---
It's worth noting that this _always_ escapes a non-empty project description, which means that descriptions that were not previously wrapped in `"`s' will be. I'm not sure how worth it is to do a _conditional_ escape (i.e. only escape if not escaping would cause a problem), but willing to change.
Side-note: I had no idea where to list this test in the (very large) `create_test.dart`, so I did my best :)
Starting in Xcode 15, the simulator is no longer included in Xcode and must be downloaded and installed separately.
If you try to run flutter and the simulator is missing, you'll get an error like
```
xcodebuild: error: Unable to find a destination matching the provided destination specifier:
{ id:B1234A5C-67B8-901D-B2CB-FE34F56BDE78 }
Ineligible destinations for the "Runner" scheme:
{ platform:iOS, id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder, name:Any iOS Device, error:iOS 17.0 is not installed. To use with Xcode, first download and install the platform }
```
Print a pretty error to make it easier for developers to know what to do.
Part 2 of https://github.com/flutter/flutter/issues/129558.
This PR fixes ignoring when random positional arguments added to the
`flutter gen-l10n`.
So we are no longer able to call `flutter gen-l10n hello world` or
`flutter gen-l10n --format false`.
Fixes https://github.com/flutter/flutter/issues/118203
`resultBundlePath` is meant to be a directory. In the `xcodebuild --help`, it describes it as a directory:
```
-resultBundlePath PATH specifies the directory where a result bundle describing what occurred will be placed
```
This PR changes our usage of it from a file to a directory so that it gets deleted correctly between reruns.
Fixes https://github.com/flutter/flutter/issues/129954.
Adding debugging for https://github.com/flutter/flutter/issues/129836.
Takes a screenshot when startup test takes too long (10 minutes).
Also, removes some old debugging and add new debugging message.
The type variable `T`, when used as an expression, will always be a
`Type`. The type test `T is! List` is always true (as is `T is Type`).
This expression will become a warning in the analyzer in some upcoming
release of the Dart SDK.
This `assert` was added in a PR which reapplied an earlier PR, however
the earlier PR did not include this assert. I do not see any discussion
indicating the intent of this assert.
The impact of testing this `T` in any way is low - this is a private
class so we can see all the uses and know that the only type bound to
`T` is `Uri`. Avoid the upcoming diagnostic and remove the assert
entirely. This maintains existing behavior but ignores the potential
intent for the check.
To avoid analyzer warnings when utf8.encode() will return the more
precise Uint8List type, we use const Utf8Encoder().convert() which
already returns Uint8List
See https://github.com/dart-lang/sdk/issues/52801
**Original Description:**
> Service extensions are unable to handle requests when the isolate they
were registered on is paused. The DevTools launcher logic was waiting
for some service extension invocations to complete before advertising
the already active DevTools instance, but when --start-paused was
provided these requests would never complete, preventing users from
using DevTools to resume the paused isolate.
>
> Fixes https://github.com/flutter/flutter/issues/126691
**Additional changes in this PR:**
The failures listed in https://github.com/flutter/flutter/pull/128117
appear to be related to a shutdown race. It's possible for the test to
complete while the tool is in the process of starting and advertising
DevTools, so we need to perform a check of `_shutdown` in
`FlutterResidentDevtoolsHandler` before advertising DevTools.
Before the original fix, this check was being performed immediately
after invoking the service extensions, which creates an asynchronous gap
in execution. With #126698, the callsite of the service extensions was
moved and the `_shutdown` check wasn't, allowing for the tool to attempt
to advertise DevTools after the DevTools server had been cleaned up.
---------
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
I intend to edit `toBeginningOfSentenceCase`'s return value to be non-nullable because it really is never null. That will mean that non-null asserts around it will become flagged as unnecessary, although right now they are necessary. So, apply a workaround - instead use a function that does a non-null assert without triggering any lints even after it becomes unnecessary.
Flutter web uses requireJS in `debug` mode to assemble a DDC-compiled app from a bunch of small files ("modules").
This caused that `canvaskit.js` (and all other modules that used a browserify-like loading header) didn't work because they attempted to use the `define` function provided by Flutter's instance of `requireJS` (which kept the defined modules private, rather than as globals on the page, as the users of the JS expected).
A [fix](https://github.com/flutter/engine/pull/27342) was added to `flutter/engine` to trick loaders into *not* using the `requireJS` module loader, but a recent change in the fix's js-interop layer *subtly* changed its JS output on the page (objects went from `undefined` to `null`), causing this:
* https://github.com/flutter/flutter/issues/126131 (and others)
This PR hides a bit of code that is commonly used by module loaders to decide that they may use the `define` function provided by requireJS (so the engine workaround can be removed).
## Next steps
* https://github.com/flutter/engine/pull/42941
## Issues
Partially addresses: https://github.com/flutter/flutter/issues/126131 (and others)
## Tests
* Added a unit test to ensure the `delete` stays
* Manually tested with the Gallery app in `debug` mode with a bunch of user-supplied scripts that currently fail to load.
* Also tested hot restart as suggested by @nshahan
Prevent the cli from crashing when a user selects a number that is not valid for `flutter run` device selection
Fixes issue:
- https://github.com/flutter/flutter/issues/129191
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Refactor the globals getter for `Analytics` to be in the context instead of having a default fallback. The current state of the tool creates a new instance every time `globals.analytics` was called
Addresses issue:
- https://github.com/flutter/flutter/issues/128535
This PR fixes issue of duplicate entries from `xcdevice list` cause devices to not show in `flutter devices`, `flutter run`, etc.
When a duplicate entry is found, use the entry without errors as the authority. If both have errors, use the one with the higher SDK as the authority.
Fixes https://github.com/flutter/flutter/issues/128719.
The `getIsolate` method returns the full list of libraries which can be huge for large apps. Using the more speficic API to only fetch what we need improves hot reload performance.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
When building the new SDK DAPs, this functionality was missed from the Flutter adapter (but added to the Dart CLI adapter).
As well as passing a VM Service URI directly, we support passing a file that can be polled for it.
This uses the same mechanism we use to obtain the VM Service URI from a Dart debug session (we run `dart --write-service-info=foo.json my_file.dart` and then poll that file which the VM will write) and is useful for users that have their own mechanism for launching an app (for example using custom Flutter embedders - see https://github.com/Dart-Code/Dart-Code/issues/3353) to provide a VM Service URI once the app is up and running.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4577.
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).
The current implementation of macOS flavor support (#119564) assumes a bundle directory that differs from both the iOS implementation and the official documentation. The [documentation](https://docs.flutter.dev/deployment/flavors) instructs developers to suffix their Xcode build configurations with `-<flavor>`, but the implementation assumes a space:
5fd9ef4240/packages/flutter_tools/lib/src/macos/application_package.dart (L174-L178)
Whereas the iOS implementation, which is the reference for the docs, assumes a `-<flavor>` suffix:
a257efc284/packages/flutter_tools/lib/src/ios/xcodeproj.dart (L482-L488)
This change replaces the empty space with the `-` character which is in line with the documentation and iOS implementation, as well as removing the sentence-casing applied to the flavor name; every bundle built with a flavor keeps the original flavor name in its filename.
*List which issues are fixed by this PR. You must list at least one issue.*
#122684.
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Unpins flutter_plugin_android_lifecycle where it is pinned. I then
1. ran `flutter update-packages --force-upgrade` (but only committed the changes within `dev/integration_tests/gradle_deprecated_settings/`, which is where it had been pinned)
2. followed by `./gradlew :generateLockfiles` from `dev/integration_tests/gradle_deprecated_settings/android/` (the lockfile was what was causing the CI dependency resolution failure, so this second step is the fix for that).
See the reason it was pinned: https://github.com/flutter/flutter/pull/121847#discussion_r1124797112 followed by the PR that pinned it: https://github.com/flutter/flutter/pull/122043
Fixes https://github.com/flutter/flutter/issues/122039
Presubmit testing and CI testing of Flutter using a custom storage location for engine artifacts must be able to use the --fatal-warnings flag without failing due to the custom artifact location.
This change adds an option that makes this warning non-fatal. The new --no-fatal-storage-url-warning flag makes the --fatal-warnings flag ignore the warning that a custom artifact download URL is being used by setting the environment variable FLUTTER_STORAGE_BASE_URL.
Bug: #127683
- [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 `///`).
The editor is set to hot-reload-on-save by default so saving while the debug session is starting currently prints an error:
Failed to Hot Reload: app 'null' not found
This change skips the call to `app.restart` if the app hasn't started yet to avoid printing an error.
This PR adds uses of the `--target-os` command line argument when
building kernel sources for precompiled applications for supported
target operating systems. The Dart CFE then:
* treats `Platform.operatingSystem` as if it were defined as the
constant string provided as an argument to the flag,
* treats `Platform.pathSeparator` as the appropriate separator for that
operating system,
* attempts to constant evaluate the initializer for any field annotated
with the `vm:platform-const` pragma, and
* attempts to constant evaluate all calls to a method annotated with the
`vm:platform-const` pragma.
The `vm:platform-const` pragma can appear in either library or user
code. If the attempt to constant evaluate the field initializer or
method call fails, then an error is thrown at kernel compilation time.
Addresses #14233.
The tests in
`packages/flutter_tools/test/general.shard/build_system/targets/common_test.dart`
have been adjusted properly to account for the new passed command line
arguments.
fixes https://github.com/flutter/flutter/issues/120408
Added two gradle tasks, one for grabing the application id, one for grabbing app link domains.
Added a new vmservices to call these two gradle tasks and return the result.
The expected work flow is that the devtool will first call a vmservices to grab all avaliable build variants. It will then choose one of the build variant and call this new services to get application id and app link domains.
Roll to engine to 4f4486b00be28183b482bbb74bbed25f4db153fe pick up dart to 3.1.0-169.0.dev.
Changes since last roll
```
4f4486b00b Roll dart to 3.1.0-169.0.dev (#42602)
```
Manual roll since rolling to dart 3.1.0-169.0.dev requires patching to expression evaluation in flutter tools
Closes https://github.com/flutter/flutter/issues/106416.
This PR adds a new `flutter config` setting named `jdk-dir`. When set, the tool will use the JDK found at this location for all Java-dependent tool operations such as building Android apps via gradle and running Android SDK tools.
