Log the details of how Chromium is about to be launched prior to running
the Chromium command, as well as the path to the Chromium executable.

This should improve our understanding of what's happening here:
https://github.com/flutter/flutter/issues/132654#issuecomment-1726630123

Adds warning to `flutter create` command that checks if detected Java version is compatible with the template AGP and template Gradle versions. If a developer is building for Android and their Java version is incompatible with either the AGP or Gradle versions that Flutter currently supports by default for new Flutter projects, then

- a warning will show noting the incompatibility and
- steps will be shown to fix the issue, the recommended option being to configure a new compatible Java version given that Flutter knows we can support the template Gradle/AGP versions and updating them manually may be risky (feedback on this approach would be greatly appreciated!)

Given that the template AGP and Gradle versions are compatible, this PR assumes that the detected Java version may only conflict with one of the template AGP or Gradle versions because:
 - the minimum Java version for a given AGP version is less than the maximum Java version compatible for the minimum Gradle version required for that AGP version (too low a Java version will fail AGP compatibility test, but not Gradle compatibility).
- the maximum Java version compatible with minimum Gradle version for a given AGP version is higher than minimum Java version required for that AGP version (too high a Java version will fail Gradle compatibility test, but not AGP compatibility test).

Fixes https://github.com/flutter/flutter/issues/130515 in the sense that `flutter create foo`; `cd foo`; `flutter run` should always be successful.

More up to date version of https://github.com/flutter/flutter/pull/133786.

Fixes https://github.com/flutter/flutter/issues/111304

Reverts flutter/flutter#134031

context: b/301051367
Looked at the error message from the broken TAP target, but seems like the failure might be non trivial to resolve. Would it be okay if we revert this for now while it is being triaged?

This PR modifies the web build slightly to create an `AssetManifest.json`, that is a JSON(base64)-encoded version of the `AssetManifest.bin` file.

_(This should enable all browsers to download the file without any interference, and all servers to serve it with the correct headers.)_

It also modifies Flutter's `AssetManifest` class so it loads and uses said file `if (kIsWeb)`.

### Issues

* Fixes https://github.com/flutter/flutter/issues/124883

### Tests

* Unit tests added.
* Some tests that run on the Web needed to be informed of the new filename, but their behavior didn't have to change (binary contents are the same across all platforms).
* I've deployed a test app, so users affected by the BIN issue may take a look at the PR in action:
  * https://dit-tests.web.app

## Description

This removes all of the comments that are of the form "so-and-so must not be null" or "so-and-so must be non-null" from the cases where those values are defines as non-nullable values.

This PR removes them from the library in the repo that don't have anything to do with the framework.

This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some.

In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow.

This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases.  I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these).

## Related PRs
- https://github.com/flutter/flutter/pull/134984
- https://github.com/flutter/flutter/pull/134991
- https://github.com/flutter/flutter/pull/134992
- https://github.com/flutter/flutter/pull/134993

## Tests
 - Documentation only change.

When retrying to connect to the device during app launch, don't uninstall the app first.

Latest test flake for https://github.com/flutter/flutter/issues/120808:
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8770202475999850785/+/u/run_hot_mode_dev_cycle_ios__benchmark/test_stdout

Shows that it uninstalled and then tried debugging and failed, which would make sense since the app wasn't installed anymore.
```
[2023-09-11 18:02:24.555646] [STDOUT] stdout: [   +6 ms] Lost connection to device. Trying to connect again...
[2023-09-11 18:02:24.556949] [STDOUT] stdout: [   +1 ms] executing: /opt/s/w/ir/x/w/recipe_cleanup/tmp53fs1szo/flutter sdk/bin/cache/artifacts/libimobiledevice/idevicesyslog -u 00008030-00144DA10185402E
[2023-09-11 18:02:24.557323] [STDOUT] stdout: [        ] executing: script -t 0 /dev/null /opt/s/w/ir/x/w/recipe_cleanup/tmp53fs1szo/flutter sdk/bin/cache/artifacts/ios-deploy/ios-deploy --id 00008030-00144DA10185402E --bundle build/ios/iphoneos/Flutter Gallery.app --app_deltas build/ios/app-delta --uninstall --noinstall --debug --no-wifi --args --enable-dart-profiling --disable-vm-service-publication --enable-checked-mode --verify-entry-points
[2023-09-11 18:02:24.578010] [STDOUT] stdout: [  +20 ms] [....] Waiting for iOS device to be connected
[2023-09-11 18:02:24.712631] [STDOUT] stdout: [ +134 ms] [....] Using 00008030-00144DA10185402E (N104AP, iPhone 11, iphoneos, arm64e, 16.2, 20C65) a.k.a. 'iPhone 11'.
[2023-09-11 18:02:24.712725] [STDOUT] stdout: [        ] ------ Uninstall phase ------
[2023-09-11 18:02:24.818293] [STDOUT] stdout: [ +105 ms] [ OK ] Uninstalled package with bundle id io.flutter.examples.gallery
[2023-09-11 18:02:24.906833] [STDOUT] stdout: [  +88 ms] ------ Debug phase ------
[2023-09-11 18:02:24.906924] [STDOUT] stdout: [        ] Starting debug of 00008030-00144DA10185402E (N104AP, iPhone 11, iphoneos, arm64e, 16.2, 20C65) a.k.a. 'iPhone 11' connected through USB...
[2023-09-11 18:02:25.285252] [STDOUT] stdout: [ +378 ms] [  0%] Looking up developer disk image
[2023-09-11 18:02:25.529937] [STDOUT] stdout: [ +244 ms] [ 90%] Mounting developer disk image
[2023-09-11 18:02:25.545261] [STDOUT] stdout: [  +15 ms] [ 95%] Developer disk image already mounted
[2023-09-11 18:02:25.587923] [STDOUT] stdout: [  +42 ms] Detected path to iOS debug symbols: "Symbol Path: /Users/swarming/Library/Developer/Xcode/iOS DeviceSupport/16.2 (20C65) arm64e/Symbols"
[2023-09-11 18:02:25.857177] [STDOUT] stdout: [ +269 ms] Script started, output file is /dev/null
[2023-09-11 18:02:25.857259] [STDOUT] stdout: [        ] Script done, output file is /dev/null
[2023-09-11 18:02:25.857511] [STDOUT] stdout: [        ] ios-deploy exited with code 0
[2023-09-11 18:02:25.858066] [STDOUT] stderr: [        ] Could not run build/ios/iphoneos/Flutter Gallery.app on 00008030-00144DA10185402E.
[2023-09-11 18:02:25.858130] [STDOUT] stderr: [        ] Try launching Xcode and selecting "Product > Run" to fix the problem:
[2023-09-11 18:02:25.858214] [STDOUT] stderr: [        ]   open ios/Runner.xcworkspace
[2023-09-11 18:02:25.858537] [STDOUT] stdout: [        ] Installing and launching... (completed in 52.4s)
[2023-09-11 18:02:25.858956] [STDOUT] stderr: [        ] Error launching application on iPhone 11.
```

Support for FFI calls with `@Native external` functions through Native assets on Linux. 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 Linux.

Mainly follows the design of https://github.com/flutter/flutter/pull/130494.

Some differences are:

* Linux does not support cross compiling or compiling for multiple architectures, so this has not been implemented.
* Linux has no add2app.

The assets copying is done in the install-phase of the CMake build of a flutter app.
CMake requires the native assets folder to exist, so we create it also when the feature is disabled or there are no assets.

### Tests

This PR adds new tests to cover the various use cases.

* packages/flutter_tools/test/general.shard/linux/native_assets_test.dart
  * Unit tests the Linux-specific part of building native assets.

It also extends various existing tests:

* packages/flutter_tools/test/integration.shard/native_assets_test.dart
  * Runs (incl hot reload/hot restart), builds, builds frameworks for Linux and flutter-tester.

…k settings

the show build settings xcode command can only accept one of the target or scheme flag. Therefore I make them optional.

Speeds up the native assets target in the backend by

1. changing other targets `gen_dart_plugin_registrant` and
`release_unpack_ios` to do async I/O,
2. not reparsing the package config, and
3. not calling `dart pub deps --json` for 0 or 1 packages (fixed
package:native_assets_builder).

* https://github.com/flutter/flutter/issues/134427

```
           [   +2 ms] native_assets: Starting due to {}
           [   +2 ms] Skipping target: gen_localizations
           [   +1 ms] gen_dart_plugin_registrant: Starting due to {InvalidatedReasonKind.inputChanged: The following inputs have updated contents: /Users/dacoharkes/flt/engine/flutter/examples/hello_world/.dart_tool/package_config_subset}
           [  +33 ms] gen_dart_plugin_registrant: Complete
           [ +107 ms] release_unpack_ios: Complete
           [  +60 ms] Writing native_assets.yaml.
           [   +7 ms] Writing /Users/dacoharkes/flt/engine/flutter/examples/hello_world/.dart_tool/flutter_build/be2692bbfbc0b9a27fcd2422d52354c6/native_assets.yaml done.
           [        ] native_assets: Complete
```

->

```
           [   +4 ms] native_assets: Starting due to {}
           [        ] Skipping target: gen_localizations
           [   +1 ms] gen_dart_plugin_registrant: Starting due to {InvalidatedReasonKind.inputChanged: The following inputs have updated contents: /Users/dacoharkes/flt/engine/flutter/examples/hello_world/.dart_tool/package_config_subset}
           [  +31 ms] Writing native_assets.yaml.
           [   +8 ms] Writing /Users/dacoharkes/flt/engine/flutter/examples/hello_world/.dart_tool/flutter_build/f9451a65a465bfab70d004e21d6cc1d6/native_assets.yaml done.
           [   +1 ms] native_assets: Complete
```

## 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 `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] All existing and new tests are passing.


<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[test-exempt]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#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/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat

Fixes https://github.com/flutter/flutter/issues/130212

Fix `Unresolved variable or type 'serviceWorkerVersion'` in the `_getNewServiceWorker` function.  

Supersedes https://github.com/flutter/flutter/pull/130206

Fixes https://github.com/flutter/flutter/issues/134566.

Prior to this fix, `ShutdownHooks` were run in the private helper
function `_exit()` defined in the `package:flutter_tools/runner.dart`
library. Independent of this, the tool had signal handling logic that
traps SIGINT and SIGTERM. However, these handlers called `exit()` from
`dart:io`, and didn't run these hooks.

This PR moves the `_exit()` private helper to
`package:flutter_tools/src/base/process.dart` and renames it to
`exitWithHooks()`, so that it can be called by the signal handlers in
`package:flutter_tools/src/base/signals.dart`.

Xcode uses the CONFIGURATION_BUILD_DIR build setting to determine the location of the bundle to build and install. When launching an app via Xcode with the Xcode debug workflow (for iOS 17 physical devices), temporarily set the CONFIGURATION_BUILD_DIR to the location of the bundle so Xcode can find it.

Also, added a Xcode Debug version of the `microbenchmarks_ios` integration test since it uses `flutter run --profile` without using `--use-application-binary`.

Fixes https://github.com/flutter/flutter/issues/134186.

Fixes:
- #132258

New feature in upcoming Dart 3.2. See https://github.com/dart-lang/language/issues/2020. Feature is enabled by bumping the min SDK version to 3.2.

Part of https://github.com/flutter/flutter/issues/134476.

Fixes https://github.com/flutter/flutter/issues/133404.

Per the dart2js team on the linked issue, `-O0` is not intended for end users, but more for actual debugging/development of the compiler.

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.

ios version of https://github.com/flutter/flutter/pull/131009/files

Fixes https://github.com/flutter/flutter/issues/134067

Sometimes `ios-deploy` loses connection to the device after installing, starting debugserver, and launching. This is shown with an error message like:
```
Process 579 exited with status = -1 (0xffffffff) lost connection
```
This happens frequently in our CI system: https://github.com/flutter/flutter/issues/120808

Usually in CI, on retry it'll work and pass - so this is an attempt to retry without failing the test first. It's not guaranteed to fix since we're unable to recreate this error locally.

Fixes https://github.com/flutter/flutter/issues/133086

Fixes https://github.com/flutter/flutter/issues/133441

…on file

The deeplink validation tool will become an static app so it can't no longer access vm services.

The goal will be then to turn them into flutter analyze command similar to `flutter analyze --android --[options]` that static app can use on.

This pr only removes vm services and turn the api to dump a output file instead of printing everything to stdout.

Flutter doctor warns if the user is updating Visual Studio or has paused
a Visual Studio update. The current output recommends reinstalling
Visual Studio. This is unnecessary as the user should be able to use the
Visual Studio Installer app to complete the installation:


![image](https://github.com/flutter/flutter/assets/737941/49547413-ece1-4214-a971-f512bc39419f)

This message is covered by this existing test:


https://github.com/flutter/flutter/blob/229b74d987720a0437039b6e44e13f20fb94ad51/packages/flutter_tools/test/general.shard/windows/visual_studio_validator_test.dart#L68-L81

## 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] 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/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[test-exempt]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#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/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat

To implement windows-arm64 support, it is needed to add architecture as a subdirectory (https://github.com/flutter/flutter/issues/129805).

In short, when performing a flutter windows build, we have:
- Before: build/windows/runner/Release/gallery.exe
- After: build/windows/x64/runner/Release/gallery.exe

This convention follows what flutter linux build does.

Addresses: https://github.com/flutter/flutter/issues/129805
Addresses: https://github.com/flutter/flutter/issues/116196

Design doc: [flutter.dev/go/windows-arm64](https://flutter.dev/go/windows-arm64)

This is the last batch of web-only API migration.

Depends on https://github.com/flutter/engine/pull/44516

Fixes https://github.com/flutter/flutter/issues/52899
Fixes https://github.com/flutter/flutter/issues/126831

It would be helpful for debugging if we can choose to also receive remote verbose logs.

...and add a test so we remember to keep it in sync.

Fixes #133055

Blocking issue (https://github.com/dart-lang/linter/issues/453) for this lint has been resolved.

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.

Closes #132245.

Addresses the other part of https://github.com/flutter/flutter/issues/132711

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.

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](https://luci-milo.appspot.com/raw/build/logs.chromium.org/flutter/led/vashworth_google.com/04e485a0b152a0720f5e561266f7a6e4fb64fc76227fcacc95b67486ae2771e7/+/build.proto)
* [Post-fix success](https://luci-milo.appspot.com/raw/build/logs.chromium.org/flutter/led/vashworth_google.com/d454a3e181e1a97692bdc1fcc197738fe04e4acf1cb20026fd040fd78513f3b0/+/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].*