Since applink validation tool is going to be a static tool, It won't have access to vmservices.
[flutter.dev/go/static-tooling-in-devtools](http://flutter.dev/go/static-tooling-in-devtools)
I remove the vm services and also update the deeplink task to also include path pattern and custom scheme
http://go/android-applink-apis (internal only)
Fixes https://github.com/flutter/flutter/issues/133093
When I introduced the new, more robust version file `//flutter/bin/cache/version.json` in https://github.com/flutter/flutter/pull/124558, I changed `class FlutterVersion` into an abstract interface, implemented by `_FlutterVersionFromGit` (which is essentially the previous behavior) and `_FlutterVersionFromFile`, which merely reads the data it would have computed via git from `//flutter/bin/cache/version.json`.
While doing this, I made `_FlutterVersionFromGit.ensureVersionFile()` to be a no-op, since I assumed this would not be necessary since we already had a version file in the cache. However, this method was what was previously responsible for ensuring `//flutter/version` existed on disk. This means that if, for whatever reason, the user had `//flutter/bin/cache/flutter.version.json` present but NOT `//flutter/version`, the tool would have never created that file, and they would hit the tool crash seen in https://github.com/flutter/flutter/issues/133093.
This fixes the tool by ensuring `//flutter/version` exists regardless of if we're hydrating `FlutterVersion` from `//flutter/bin/cache/flutter.version.json` or not.
This makes two changes to prepare for incoming changes to skwasm in the web engine:
* We will (at least for now) be depending on the `WebAssembly.Function` constructor in `skwasm`, which is hidden behind the `--experimental-wasm-type-reflection` flag. We need to pass that when running skwasm benchmarks.
* We are going to be upgrading the skwasm build to a newer version of emscripten, which exposes the wasm exports via the `wasmExports` property instead of the `asm` property. Make sure to support either, if passed.
1. Remove vm service registration
2. combine print<variant>ApplicationId and print<variant>AppLinkDomain into one task dump<variant>AppLinkSettings, which dump all the data in a json file
The deeplink validation tool will be a static app in devtool instead of regular app. A Static app doesn't require a running app; therefore, we can't call these API through vmservices. I decided to convert these API into flutter analyzer command, which will be done in a separate PR https://github.com/flutter/flutter/pull/131009.
The reason these print tasks are converted into file dumps is to reduce the amount of data encoding and decoding. Instead of passing data through stdout, the devtool can read the files generated by gradle tasks instead.
*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].*
Starting in Xcode 15, when building macOS, DT_TOOLCHAIN_DIR cannot be used to evaluate LD_RUNPATH_SEARCH_PATHS or LIBRARY_SEARCH_PATHS. `xcodebuild` error message recommend using TOOLCHAIN_DIR instead.
Since Xcode 15 isn't in CI, I tested it in a one-off `led` test:
* [Pre-fix failure](04e485a0b1/+/build.proto)
* [Post-fix success](d454a3e181/+/build.proto)
Fixes https://github.com/flutter/flutter/issues/132755.
Currently, flutter pub get generates localizations if there exists an l10n.yaml file where synthetic-package is not false. However, for any user who needs to turn off synthetic-package, their localizations are not generated. This PR should make the behavior more consistent. (Also it seems good to make it so that running flutter pub get once resolves all the dependencies so that people can get to work without running flutter gen-l10n manually.)
Fixes https://github.com/flutter/flutter/issues/84979.
This PR adjusts the quoting of the project description not not apply twice in the index.html / manifest.json of web builds.
*List which issues are fixed by this PR. You must list at least one issue.*
Fixes https://github.com/flutter/flutter/issues/131834
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Partial work towards https://github.com/flutter/flutter/issues/132245.
The goal here is to "sniff" out any missing pieces that would block engine builds, rolls, benchmarks and so on before requiring humans to provide the parameter. The implementation is based on a [short discussion with @christopherfujino](https://discord.com/channels/608014603317936148/608022056616853515/1141503921546875110):
@matanlurey:
> Not sure whether to post here or â hackers-infra-ð¡ , but is there a way to (and is it advisable to) detect whether the tool is running in a CI environment? I'd like to "soft enforce" --local-engine-host being provided strictly on CI, make sure that lands well, and then "upgrade" it to being non-CI invocations as well (re: https://github.com/flutter/flutter/issues/132245).
>
> Also happy to get talked out of this idea ð
@christopherfujino:
> we have a check, lemme find it
> whether or not it is advisable, idk
> https://github.com/flutter/flutter/blob/flutter-3.14-candidate.0/packages/flutter_tools/lib/src/base/bot_detector.dart#L30
>
> (...)
>
> is your desire to get early signal before enforcing t his for humans to prevent functionality churn of landing and reverting and re-landing?
>
> (yes)
>
> uhh, sure, that's advisable ð
Partial work towards https://github.com/flutter/flutter/issues/132245.
I also couldn't help myself to do a very minor refactor and add some comments to `LocalEngineInfo` because I was getting confused myself implementing it.
PR #132346 added the use of --local-engine-host to flutter_tools internals, and had an error on one line. Fix that error, to use the correct field name.
The error occurs when building plugins with the changed tools.
Partial work towards https://github.com/flutter/flutter/issues/132245.
I made a minor refactor to test-only code because it was too confusing
to have 2 optional parameters that are technically required together,
but otherwise all other changes *should* be pass throughs. That being
said, I can't say I totally understand the Gradle stuff so I could use a
hand double checking that.
At some point in the near future, we'll start an Impeller on Android preivew - and later make it the default. Unlike Skia, Impeller does not have a fallback software rendering mode. We'd like to stop suggesting this as an option now, and in the future remove the option to force software rendering.
Once impeller is the default, asking for software rendering on Android will result in either an error or falling back to Skia.
Fixes a couple of issues introduced in new iOS 17 physical device tooling: https://github.com/flutter/flutter/pull/131865.
1) Duplicate messages were being filtered out too aggressively.
For example, if on the counter app, you printed "Increment!" on button click, it would only print once no matter how many times you clicked.
Sometimes more than one log source is used at a time and the original intention was to filter duplicates between two log sources, so it wouldn't print the same message from both logs. However, it would also filter when the same message was added more than once via the same log.
The new solution distinguishes a "primary" and a "fallback" log source and prefers to use the primary source unless it's not working, in which it'll use the fallback. If the fallback is faster than the primary, the primary will exclude the logs received by the fallback in a 1-to-1 fashion to prevent too-aggressive filtering. Once a flutter-message has been received by the primary source, fallback messages will be ignored.
Note: iOS < 17 did not regress.
2) There was a race condition between the shutdown hooks and exiting XcodeDebug that was causing a crash when deleting a file that doesn't exist. This only affects CI - for the new integration tests and when testing with iOS 17 physical devices.
Towards https://github.com/dart-lang/test/issues/2065
The flutter test runner uses the copy of `host.dart.js` from the copy of
`package:test` that surfaces in the pub solve for `flutter_tool`. This
copy has been updated to allow either the old pattern of communication,
or this new pattern. The new pattern removes an extra hop and use of the
frame `window.onMessage` messages.
Partial work towards https://github.com/flutter/flutter/issues/132245.
Other than updating error messages, and passing `$LOCAL_ENGINE_HOST`
downwards, this PR should not change the behavior of any existing
workflows or code (i.e. it's purely additive).
Implement expected functionalities when supplying `--web-launch-url` and/or `--web-hostname` arguments to `flutter drive`.
- `--web-launch-url` now sets the starting url for the (headless) browser
- Which for example means you can start at a certain part of the app at the start of your integration test
- `--web-hostname` now sets the hostname where the target of flutter drive will be hosted
- Which allows you to set something other than localhost (allowing access via a reverse-proxy for example)
Fixes#118028
Fixes: https://github.com/flutter/flutter/issues/124970
Part of https://github.com/flutter/flutter/issues/47161
Before this change, there were two places we overrode the `Artifacts` in a Zone:
1. if/when we parse local-engine CLI options: 1cf3907407/packages/flutter_tools/lib/src/runner/flutter_command_runner.dart (L281)
2. an additional override for fuchsia platform dill (no longer used, deleted in this PR): 1cf3907407/packages/flutter_tools/lib/src/commands/attach.dart (L274)
Note 1 above creates a new instance of `Artifacts.getLocalEngine()`. In this flow, there exist two instances of `Artifacts`:
1. The default fallback instance of `CachedArtifacts` (which gets all artifacts from flutter/bin/cache), instantiated in context_runner.dart: 1cf3907407/packages/flutter_tools/lib/src/context_runner.dart (L137)
2. An instance of `CachedLocalEngineArtifacts` created in the command runner once the CLI options have been parsed: 1cf3907407/packages/flutter_tools/lib/src/runner/flutter_command_runner.dart (L281)
The regression happened when we direct injected the Artifacts 1 from above BEFORE we parsed the local-engine flag, and then used this in the second zone override, and then when creating the `FlutterDevice` there are multiple calls to `globals.artifacts` returned it when it should have returned Artifacts 2: 1cf3907407/packages/flutter_tools/lib/src/resident_runner.dart (L80)
Device.artifactOverrides was originally introduced in https://github.com/flutter/flutter/pull/32071, but is no longer used, so I deleted it.
I also removed direct injection of `Artifacts` to the attach sub-command, because that class now no longer references artifacts.
I believe the ideal true fix for this would be to:
1. Migrate all leaf calls to `globals.artifacts` to use direct injection (in this case, the offending invocations were in [`FlutterDevice.create()`](1cf3907407/packages/flutter_tools/lib/src/resident_runner.dart (L80-L218)), but I'm not sure that something else would not have broken later)
2. Ensure we are always direct injecting the desired instance of `Artifacts`--that is, if the user desires local engine artifacts, that we are passing an instance of `CachedLocalEngineArtifacts`.
a. Alternatively, and probably simpler, teach `CachedArtifacts` to know about the local engine. This would mean parsing the global CLI options BEFORE we ever construct any instance of `Artifacts`.
As an overall recommendation for implementing https://github.com/flutter/flutter/issues/47161, in the overall tree of tool function calls, we should probably migrate the leaves first (that is, migrate the sub-commands last). We should also audit and reconsider any usage of `runZoned()` or `context.run()` for the purpose overriding zoneValues.
Closes https://github.com/flutter/flutter/issues/132162.
I did a tiny bit of minor cleanup but didn't want to go 🍔 beyond the
scope of this change. After it lands I'll update the Wiki.
## Before
```bash
$ fl run \
--local-engine-src-path=$ENGINE \
--local-engine=android_debug_unopt_arm64
```
... would try to use `host_debug_unopt` (i.e. Rosetta).
## After
```bash
$ fl run \
--local-engine-src-path=$ENGINE \
--local-engine=android_debug_unopt_arm64 \
--local-engine-host=host_debug_unopt_arm64
```
... uses `host_debug_unopt_arm64`, as specified.
---
/cc @jonahwilliams @gaaclarke @zanderso
Context: https://github.com/flutter/flutter/issues/131862
This PR injects a "realm" component to the storage base URL when the contents of the file `bin/internal/engine.realm` is non-empty.
As documented in the PR, when the realm is `flutter_archives_v2`, and `bin/internal/engine.version` contains the commit hash for a commit in a `flutter/engine` PR, then the artifacts pulled by the tool will be the artifacts built by the presubmit checks for the PR.
This works for everything but the following two cases:
1. Fuchsia artifacts are not uploaded to CIPD by the Fuchsia presubmit builds.
2. Web artifacts are not uploaded to gstatic by the web engine presubmit builds.
For (1), the flutter/flutter presubmit `fuchsia_precache` is driven by a shell script outside of the repo. It will fail when the `engine.version` and `engine.realm` don't point to a post-submit engine commit.
For (2), the flutter/flutter web presubmit tests that refer to artifacts in gstatic hang when the artifacts aren't found, so this PR skips them.
This PR includes the following changes. These changes only apply to iOS 17 physical devices.
| Command | Change Description | Changes to User Experience |
| ------------- | ------------- | ------------- |
| `flutter run --release` | Uses `devicectl` to install and launch application in release mode. | No change. |
| `flutter run` | Uses Xcode via automation scripting to run application in debug and profile mode. | Xcode will be opened in the background. Errors/crashes may be caught in Xcode and therefore may not show in terminal. |
| `flutter run --use-application-binary=xxxx` | Creates temporary empty Xcode project and use Xcode to run via automation scripting in debug and profile. | Xcode will be opened in the background. Errors/crashes may be caught in Xcode and therefore may not show in terminal. |
| `flutter install` | Uses `devicectl` to check installed apps, install app, uninstall app. | No change. |
| `flutter screenshot` | Will return error. | Will return error. |
Other changes include:
* Using `devicectl` to get information about the device
* Using `idevicesyslog` and Dart VM logging for device logs
Note:
Xcode automation scripting (used in `flutter run` for debug and profile) does not work in a headless (without a UI) interface. No known workaround.
Fixes https://github.com/flutter/flutter/issues/128827, https://github.com/flutter/flutter/issues/128531.
Redo of https://github.com/flutter/flutter/pull/130728 - code is the same as before. That PR was stuck in Google testing and then I messed up the rebase so started over.
----
Starting in Xcode 15, the simulator is no longer included in Xcode and must be downloaded and installed separately. This adds a validation to `flutter doctor` to warn when the needed simulator runtime is missing.
Validation message looks like:
```
[!] Xcode - develop for iOS and macOS (Xcode 15.0)
! iOS 17.0 Simulator not installed; this may be necessary for iOS and macOS development.
To download and install the platform, open Xcode, select Xcode > Settings > Platforms,
and click the GET button for the required platform.
For more information, please visit:
https://developer.apple.com/documentation/xcode/installing-additional-simulator-runtimes
```
It may also show an error like this when something goes wrong when checking for the simulator:
```
[!] Xcode - develop for iOS and macOS (Xcode 15.0)
â Unable to find the iPhone Simulator SDK.
```
Note: I'm unsure of in the future if the SDK and the simulator runtime will need to match the exact version or just the major. For now, it only checks against the major version.
Part 3 of https://github.com/flutter/flutter/issues/129558.
Fixed code for the Uri as it includes the period at the end as the part of Uri parsing previously.
As for example:
```
A crash report has been written to /Users/andrewkolos/Desktop/asset_transformers_test/flutter_03.log.
```
Many terminals are unable to follow the link because it includes the period in the end as part of it. This PR simply removes the period in the end so that it is clickable in many systems (e.g. by `alt` -clicking on it in an embedded bash terminal, VSCode).
```
A crash report has been written to /Users/andrewkolos/Desktop/asset_transformers_test/flutter_03.log
```
Fixes: #131166
In the legacy VS Code DAP, we would deserialise the Flutter.Error event
and provide some basic colouring (eg. stack frames are faded if not from
user code and the text is split between stdout/stderr to allow the
client to colour it).
In the new DAPs we originally used `renderedErrorText` which didn't
support either of these. This change adds changes to use the structured
data (with some basic parsing because the source classes are in
package:flutter and not accessible here) to provide a similar
experience.
It would be nicer if we could use the real underlying Flutter classes
for this deserialisation, but extracting them from `package:flutter` and
removing all dependencies on Flutter is a much larger job and I don't
think should hold up providing improved error formatting for the new
DAPs.
Some comparisons:
Improves #119596. The tests remain valid, so no tests were updated in the request.
This does not resolve issue #128932, it's handled by another part of the code.
To preserve backward compatibility with the old parser which would
ignore syntax errors, this PR introduces a way to treat the special
characters `{` and `}` in the following way:
1. If we encounter a `{` which searching for a string token and this `{`
is not followed by a valid placeholder, then we treat the `{` as a
string and continue lexing for strings.
2. If we encounter a `}` while not within some expression (i.e.
placeholders, arguments, plurals, or selects), then we treat the `}` as
a string and continue lexing for strings.
This makes it so that
```
"helloWorld": "{ } { placeholder }",
"@@helloWorld": {
"placeholders": {
"placeholder" {}
}
}
```
treats the `{ }` as a string while `{ placeholder } ` is treated as a
placeholder.
Fixes https://github.com/flutter/flutter/issues/122404.
The display name will fallback to CFBundleName if CFBundleDisplayName is absent.
*List which issues are fixed by this PR. You must list at least one issue.*
Fixes https://github.com/flutter/flutter/issues/120553
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
The daemon ignores all device discovery that is not a PollingDeviceDiscovery. Make ProxiedDevices a PollingDeviceDiscovery so that it can be used in flutter daemon.
Note that there is a TODO item added in the test, which I intend to attempt fixing in a subsequent PR.
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.
Manual roll is needed because incoming dart sdk requires updated version
vm_snapshot_analysis (>=0.7.4).
5ae09b8b4f...7c83ea3e85
```
7c83ea3e85 Reland "Manual roll Dart SDK from 2d98d9e27dae to 0b07debd5862 (21 revisions) (#43457)" (#43472)
9ef3e8d533 Roll Skia from 5eba922297bb to 93c92f97f5ab (2 revisions) (#43471)
```
Remove implementation of SuitePlatform from the test as well. Remove use
of fake cwd from SuitePlatform as it can't be properly faked.
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
