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].*
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].*
The file was becoming harder to deal with as it manually sets up a /lib/l10n directory with a `MemoryFileSystem` in every single test. This PR wraps this process in a helper function `setupLocalizations` and also provides a helper function `getGeneratedFileContent` which helps fetch the respective output file given the locale string.
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
The app.detach command will close the VM service connection, which yields an app.stop event in the daemon protocol. The daemon does not guarantee any ordering between this event and the response to the app.detach.
See https://github.com/flutter/flutter/issues/128546
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.
Fixes https://github.com/flutter/flutter/issues/127090.
https://github.com/flutter/flutter/pull/122505 did a few things to speed up the first asset load that a flutter app performs. One of those things was to not include the main asset in its own list of variants in the asset manifest. The idea was that we know that the main asset always exists, so including it in its list of variants is a waste of storage space and loading time (even if the cost was tiny).
However, the assumption that the main asset always exists is wrong. From [Declaring resolution-aware image assets](https://docs.flutter.dev/ui/assets-and-images#resolution-aware), which predates https://github.com/flutter/flutter/pull/122505:
> Each entry in the asset section of the pubspec.yaml should correspond to a real file, with the exception of the main asset entry. If the main asset entry doesnât correspond to a real file, then the asset with the lowest resolution is used as the fallback for devices with device pixel ratios below that resolution. The entry should still be included in the pubspec.yaml manifest, however.
For example, it's valid to declare `assets/image.png` as an asset even if only `assets/3x/image.png` exists on disk.
This fix restores older behavior of including a main asset as a variant of itself in the manifest if it exists.
This fix also includes a non-user-visible behavior change:
* `"dpr"` is no longer a required field in the asset manifest's underlying structure. For the main asset entry, we do not include `"dpr"`. It makes less sense for the tool to decide what the default target dpr for an image should be. This should be left to the framework.
Always pass the space code point (`0x20`) to the font subsetter when targetting web because the web engine relies on that character to calculate a font's height.
Fixes#127270
Reverts flutter/flutter#126698
There are a bunch of tool crashes on CI that start with this commit. I'm
not sure this PR is the cause because there is no backtrace from the
tool on the crashes. The only error message is `Oops; flutter has exited
unexpectedly: "Null check operator used on a null value`.
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
Fixes#122081.
When validating an Android Studio installation, add a warning validation message when we are unable to detect the version. This is because we have logic throughout the tool (JDK/JRE-searching) that is at higher risk of failing when we don't know the version.
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.
This reverts commit a19b3436ee.
We added this logging to try and determine if the reason for Dart VM errors (https://github.com/flutter/flutter/issues/121231) was caused by some issue with the streams.
A recent test proves that is not the case:
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20platform_view_ios__start_up/11046/overview
The test shows the Dart VM url in the device log. However, the test log does NOT show a log for the Dart VM url but does show the stack trace, which all come from the main stream, which means it's not an issue with the secondary streams not receiving the log.
So reverting the debugging we added.
Addresses issues:
- https://github.com/flutter/flutter/issues/127135
- https://github.com/flutter/flutter/issues/99767
Creates a matcher class that we can use for `ProcessResult` to check for the exit code.
*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].*
## 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. :-)
Log all output of `ios-deploy` to try and determine if the issue of https://github.com/flutter/flutter/issues/121231 is with stream or with `ios-deploy`.
Note: This will cause some duplicate logs like example below but only in verbose mode
```
(lldb) 2023-05-19 13:48:19.107935-0500 Runner[2521:390363] [VERBOSE-2:FlutterDarwinContextMetalImpeller.mm(35)] Using the Impeller rendering backend.
(lldb) 2023-05-19 13:48:19.107935-0500 Runner[2521:390363] [VERBOSE-2:FlutterDarwinContextMetalImpeller.mm(35)] Using the Impeller rendering backend.
2023-05-19 13:48:19.156866-0500 Runner[2521:390612] flutter: The Dart VM service is listening on http://127.0.0.1:63508/IsFnhXJykCM=/
VM Service URL on device: http://127.0.0.1:63508/IsFnhXJykCM=/
```
