Reverts flutter/flutter#142709

Initiated by: vashworth

Reason for reverting: `Mac tool_tests_general` started failing on this commit: https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20tool_tests_general/15552/overview

Original PR Author: dcharkes

Reviewed By: {christopherfujino, chingjun, reidbaker}

This change reverts the following previous change:
Original Description:
Native assets in other build systems are not built with `package:native_assets_builder` invoking `build.dart` scripts. Instead all packages have their own blaze rules. Therefore we'd like to not depend on `package:native_assets_builder` from flutter tools in g3 at all.

This PR aims to move the imports of `native_assets_builder` and `native_assets_cli` into the `isolated/` directory and into the files with a `main` function that are not used in with other build systems.

In order to be able to remove all imports in files used by other build systems, two new interfaces are added `HotRunnerNativeAssetsBuilder` and `TestCompilerNativeAssetsBuilder`. New parameters are then piped all the way through from the entry points:

* bin/fuchsia_tester.dart
* lib/executable.dart

The build_system/targets dir is already excluded in other build systems.

So, after this PR only the two above files and build_system/targets import from `isolated/native_assets/` and only `isolated/native_assets/` import `package:native_assets_cli` and `package:native_assets_builder`.

Context:

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

Native assets in other build systems are not built with `package:native_assets_builder` invoking `build.dart` scripts. Instead all packages have their own blaze rules. Therefore we'd like to not depend on `package:native_assets_builder` from flutter tools in g3 at all.

This PR aims to move the imports of `native_assets_builder` and `native_assets_cli` into the `isolated/` directory and into the files with a `main` function that are not used in with other build systems.

In order to be able to remove all imports in files used by other build systems, two new interfaces are added `HotRunnerNativeAssetsBuilder` and `TestCompilerNativeAssetsBuilder`. New parameters are then piped all the way through from the entry points:

* bin/fuchsia_tester.dart
* lib/executable.dart

The build_system/targets dir is already excluded in other build systems.

So, after this PR only the two above files and build_system/targets import from `isolated/native_assets/` and only `isolated/native_assets/` import `package:native_assets_cli` and `package:native_assets_builder`.

Context:

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

Avoid depending on files from build_system/targets other than from top level entrypoints in flutter_tools. (#142760)

Add a new `BuildTargets` class that provides commonly used build targets. And avoid importing files from `build_system/targets` except from the top level entrypoints or from top level commands.

Also move `scene_importer.dart` and `shader_compiler.dart` into `build_system/tools` because they are not `Target` classes, but wrapper for certain tools.

With this change, we can ignore all files in `build_system/targets` internally and make PR #142709 easier to land internally. See cl/603434066 for the corresponding internal change.

Related to:
https://github.com/flutter/flutter/pull/142709
https://github.com/flutter/flutter/issues/142041

Also note that I have opted to add a new variable in `globals.dart` for `BuildTargets` in this PR, but I know that we are trying to get rid of globals. Several alternatives that I was considering:

1. Add a new field in `BuildSystem` that returns a `BuildTargets` instance. Since `BuildSystem` is already in `globals`, we can access build targets using `globals.buildSystem.buildTargets` without adding a new global variable.
2. Properly inject the `BuildTargetsImpl` instance from the top level `executable.dart` and top level commands.

Let me know if you want me to do one of the above instead. Thanks!

This implements dual compile via the newly available flutter.js bootstrapping APIs for intelligent build fallback.
* Users can now use the `FlutterLoader.load` API from flutter.js
* Flutter tool injects build info into the `index.html` of the user so that the bootstrapper knows which build variants are available to bootstrap
* The semantics of the `--wasm` flag for `flutter build web` have changed:
  - Instead of producing a separate `build/web_wasm` directory, the output goes to the `build/web` directory like a normal web build
  - Produces a dual build that contains two build variants: dart2wasm+skwasm and dart2js+CanvasKit. The dart2wasm+skwasm will only work on Chrome in a cross-origin isolated context, all other environments will fall back to dart2js+CanvasKit.
  - `--wasm` and `--web-renderer` are now mutually exclusive. Since there are multiple build variants with `--wasm`, the web renderer cannot be expressed via a single command-line flag. For now, we are hard coding what build variants are produced with the `--wasm` flag, but I plan on making this more customizable in the future.
* Build targets now can optionally provide a "build key" which can uniquely identify any specific parameterization of that build target. This way, the build target can invalidate itself by changing its build key. This works a bit better than just stuffing everything into the environment defines because (a) it doesn't invalidate the entire build, just the targets which are affected and (b) settings for multiple build variants don't translate well to the flat map of environment defines.

Add debugging for #141892 to detect when the temp file mysteriously
disappears after running devicectl.

Refactors `ShaderTarget` to make it opaque as to whether it's using Impeller or SkSL and instead has it focus on the target platform it's generating for.

ImpellerC includes SkSL right now whether you ask for it or not. 

The tester target also might need SkSL or Vulkan depending on whether `--enable-impeller` is passed.

This reverts commit f5ac225c, i.e. https://github.com/flutter/flutter/pull/137115.

This is a continuation of https://github.com/flutter/flutter/pull/142266 that was redone based on feedback to make this easier to revert in the future. The exact steps I took to create this revert:

1. Revert commit noted above
2. Fix merge conflicts, that notably involved reverting some changes in https://github.com/flutter/flutter/pull/140744 ~and https://github.com/flutter/flutter/pull/141417~ (fixed my merge to avoid the second PR from being affected)
3. Delete `packages/flutter_tools/test/integration.shard/android_plugin_skip_unsupported_test.dart` as this was added in the commit noted above

cc @Gustl22 since I couldn't tag as a reviewer

This PR increases Android's `minSdkVersion` to 21.

There are two changes in this PR aside from simply increasing the number
from 19 to 21 everywhere.

First, tests using `flutter_gallery` fail without updating the
lockfiles. The changes in the PR are the results of running
`dev/tools/bin/generate_gradle_lockfiles.dart` on that app.

Second, from
[here](https://developer.android.com/build/multidex#mdex-pre-l):
> if your minSdkVersion is 21 or higher, multidex is enabled by default
and you don't need the multidex library.

As a result, the `multidex` option everywhere is obsolete. This PR
removes all logic and tests related to that option that I could find.
`Google testing` and `customer_tests` pass on this PR, so it seems like
this won't be too breaking if it is at all. If needed I'll give this
some time to bake in the framework before landing the flutter/engine
PRs.

Context: https://github.com/flutter/flutter/issues/138117,
https://github.com/flutter/flutter/issues/141277, b/319373605

It's now possible to natively compile a flutter app for windows-arm64. Cross-compilation is not yet implemented.

Uses arm64 artifacts now available for Dart/Flutter. Platform detection is based on Abi class, provided by Dart. Depending if Dart is an arm64 or x64 binary, the Abi is set accordingly. Initial bootstrap of dart artifacts (update_dart_sdk.ps1) is checking PROCESSOR_ARCHITECTURE environment variable, which is the way to detect host architecture on Windows.

This is available only for master channel (on other channels, it fallbacks to windows-x64).

On windows-x64, it produces an x64 app. On windows-arm64, it produces an arm64 app.

This PR adds a test that reproduces the problem described in the linked issue: hot restart on the web seems to not update if the app being run is `const`.

The new test is expected to fail, until the `const` issue with hot restart in the web is resolved.

Expected failure mode is a 15s timeout in the following test:

```
02:31 +3 ~1 -1: Hot reload (index.html: Default) (with `const MyApp()`)): newly added code executes during hot restart [E]
  TimeoutException after 0:00:15.000000: Future not completed
  dart:async  _startMicrotaskLoop
  ...
```

(And then a bunch of output that I'm not 100% sure is intended :))

## Issues

* #141588

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

Reland: https://dart-review.googlesource.com/c/sdk/+/346960 has rolled into g3, so the imports should now resolve in g3 as well.

> [!CAUTION]
> _Do NOT merge if "Google Testing" bot didn't run!_

Rolls the packages from https://github.com/dart-lang/native in the native assets implementation.

Most notable we're refactoring `package:native_assets_cli` for `build.dart` use.
Therefore, all imports to that package for Flutter/Dart should be to the implementation internals that are no longer visible for `build.dart` writers. Hence all the import updates.

No behavior in Flutter apps should change.

This PR also updates the template to use the latests version of `package:native_assets_cli` which no longer exposes all the implementation details.

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

I should have made this change in https://github.com/flutter/flutter/pull/124039, but it escaped my grep search.

Packages the native assets for iOS and MacOS in frameworks.

Issue:

* https://github.com/flutter/flutter/issues/140544
* https://github.com/flutter/flutter/issues/129757

## Details

* [x] This packages dylibs from the native assets feature in frameworks. It packages every dylib in a separate framework.
* [x] The dylib name is updated to use `@rpath` instead of `@executable_path`.
* [x] The dylibs for flutter-tester are no longer modified to change the install name. (Previously it was wrongly updating the install name to the location the dylib would have once deployed in an app.)
* [x] Use symlinking on MacOS.

Includes the Engine roll from
https://github.com/flutter/flutter/pull/141841

A new version of Dart is having trouble with the tool integration test
test `passing one file with errors are detected`:
https://ci.chromium.org/ui/p/flutter/builders/try/Mac%20tool_integration_tests_2_4/31851/overview.

However the analysis server emits the expected errors when we give it
both the file without issues and the file with issues.

My guess is that the analysis server has changed it's behavior slightly
when supplied with a single malformed file.

Since the Dart roll is >20 dev versions behind, and this is the only
failing presubmit test, and it's testing something a bit weird, I
suggest we investigate the right way to test the thing that test was
attempting to cover as a follow-up.

Reverts flutter/flutter#137618
Initiated by: Jasguerrero
This change reverts the following previous change:
Original Description:
It's now possible to natively compile a flutter app for
windows-arm64. Cross-compilation is not yet implemented.

Uses arm64 artifacts now available for Dart/Flutter.
Platform detection is based on Abi class, provided by Dart. Depending if
Dart is an arm64 or x64 binary, the Abi is set accordingly.
Initial bootstrap of dart artifacts (update_dart_sdk.ps1) is checking
PROCESSOR_ARCHITECTURE environment variable, which is the way to detect
host architecture on Windows.

This is available only for master channel (on other channels, it
fallbacks to windows-x64).

On windows-x64, it produces an x64 app. On windows-arm64, it produces an
arm64 app.

It's now possible to natively compile a flutter app for
windows-arm64. Cross-compilation is not yet implemented.

Uses arm64 artifacts now available for Dart/Flutter.
Platform detection is based on Abi class, provided by Dart. Depending if
Dart is an arm64 or x64 binary, the Abi is set accordingly.
Initial bootstrap of dart artifacts (update_dart_sdk.ps1) is checking
PROCESSOR_ARCHITECTURE environment variable, which is the way to detect
host architecture on Windows.

This is available only for master channel (on other channels, it
fallbacks to windows-x64).

On windows-x64, it produces an x64 app. On windows-arm64, it produces an
arm64 app.

b/320767653

Reverts flutter/flutter#141684

Rolls the packages from https://github.com/dart-lang/native in the native assets implementation.

Most notable we're refactoring `package:native_assets_cli` for `build.dart` use.
Therefore, all imports to that package for Flutter/Dart should be to the implementation internals that are no longer visible for `build.dart` writers. Hence all the import updates.

No behavior in Flutter apps should change.

This PR also updates the template to use the latests version of `package:native_assets_cli` which no longer exposes all the implementation details.

Fair amount of typos spotted and fixed. Some of them are in comments, some of them are in code and some of them are in nondart files.

There is no need for issues since it's a typo fix.

I have doubts about [packages/flutter_tools/lib/src/ios/core_devices.dart](https://github.com/flutter/flutter/compare/master...anisalibegic:flutter:master#diff-fdbc1496b4bbe7e2b445a567fd385677af861c0093774e3d8cc460fdd5b794fa), I have a feeling it might broke some things on the other end, even though it's a typo.

[deep link]  Update a gradle task to add flag check and intent filter check to the AppLinkSettings (#141231)

These check result is used in devtool deep link validation
issue: https://github.com/flutter/flutter/issues/120408

## Pre-launch Checklist

- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [ ] I signed the [CLA].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] 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].
- [ ] 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

This PR resolves #140548. It's based on my work in #118067.

Add an option to use named argument for generated method.

Fix #116308

Relands #97823

When the tool migrated to `.flutter-plugins-dependencies`, the Gradle plugin was never changed.
Until now, the plugin had the heuristic that a plugin with a `android/build.gradle` file supported the Android platform.

Also applies schema of `getPluginDependencies` to `getPluginList` which uses a `List` of Object instead of `Properties`.

Fixes #97729
Cause of the error: https://github.com/flutter/flutter/blob/5f105a6ca7a5ac7b8bc9b241f4c2d86f4188cf5c/packages/flutter_tools/gradle/flutter.gradle#L421C25-L421C25

Fixes #98048
The deprecated line `include ":$name"` in `settings.gradle` (pluginEach) in old projects causes the `project.rootProject.findProject` to also find the plugin "project", so it is not failing on the `afterEvaluate` method. But the plugin shouldn't be included in the first place as it fails with `Could not find method implementation() for arguments` error in special cases.

Related to #48918, see [_writeFlutterPluginsListLegacy](https://github.com/flutter/flutter/blob/27bc1cf61a5b54bf655062be63050123abb617e4/packages/flutter_tools/lib/src/flutter_plugins.dart#L248).
Co-authored-by: Emmanuel Garcia <egarciad@google.com>

Restore testing deprecated settings.gradle (plugins.each).

Updated presumably by accident in #83067

Split from #137115
See also https://github.com/flutter/flutter/pull/137115#issuecomment-1781909865

> This PR relands #139690 which was reverted in #140102

This PR adds a deprecation message when Android build is using the legacy "apply script method" way of applying Flutter's Gradle plugins (that is: [`flutter.gradle`](https://github.com/flutter/flutter/blob/3.16.0/packages/flutter_tools/gradle/flutter.gradle) and [`app_plugin_loader.gradle`](https://github.com/flutter/flutter/blob/3.16.0/packages/flutter_tools/gradle/app_plugin_loader.gradle)).

See also:
- #121541
  - in particular https://github.com/flutter/flutter/issues/121541#issuecomment-1836947311
- #135392
  - and PR that add the migration guide: [#9857](https://github.com/flutter/website/pull/9857)

- I think either `logger.error` or `logger.quiet` must be used, because all other error levels are not shown during `flutter build apk` (and that's what most people use).

Solves https://github.com/flutter/flutter/pull/137115#discussion_r1388251047

Update Android SDK from 33 to 34.

Following the engine update:

* https://github.com/flutter/engine/pull/47839

Reverts flutter/flutter#139690
Initiated by: hellohuanlin
This change reverts the following previous change:
Original Description:
This PR adds a deprecation message when Android build is using the legacy "apply script method" way of applying Flutter's Gradle plugins (that is: [`flutter.gradle`](https://github.com/flutter/flutter/blob/3.16.0/packages/flutter_tools/gradle/flutter.gradle) and [`app_plugin_loader.gradle`](https://github.com/flutter/flutter/blob/3.16.0/packages/flutter_tools/gradle/app_plugin_loader.gradle)).

See also:
- #121541
  - in particular https://github.com/flutter/flutter/issues/121541#issuecomment-1836947311
- #135392
  - and PR that add the migration guide: [#9857](https://github.com/flutter/website/pull/9857)

- I think either `logger.error` or `logger.quiet` must be used, because all other error levels are not shown during `flutter build apk` (and that's what most people use).

This PR adds a deprecation message when Android build is using the legacy "apply script method" way of applying Flutter's Gradle plugins (that is: [`flutter.gradle`](https://github.com/flutter/flutter/blob/3.16.0/packages/flutter_tools/gradle/flutter.gradle) and [`app_plugin_loader.gradle`](https://github.com/flutter/flutter/blob/3.16.0/packages/flutter_tools/gradle/app_plugin_loader.gradle)).

See also:
- #121541
  - in particular https://github.com/flutter/flutter/issues/121541#issuecomment-1836947311
- #135392
  - and PR that add the migration guide: [#9857](https://github.com/flutter/website/pull/9857)

- I think either `logger.error` or `logger.quiet` must be used, because all other error levels are not shown during `flutter build apk` (and that's what most people use).

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

Based (heavily) off https://github.com/flutter/flutter/pull/104662

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

Mainly follows the design of the previous PRs.

For Android, we detect the compilers inside the NDK inside SDK.

And bundling of the assets is done by the flutter.groovy file.

The `minSdkVersion` is propagated from the flutter.groovy file as well.

The NDK is not part of `flutter doctor`, and users can omit it if no native assets have to be build.
However, if any native assets must be built, flutter throws a tool exit if the NDK is not installed.

Add 2 app is not part of this PR yet, instead `flutter build aar` will tool exit if there are any native assets.

The tree is red due a non-hermetic customer test from `macos_ui`. The
test was disabled in https://github.com/flutter/tests/pull/317 and an
issue was filed at https://github.com/macosui/macos_ui/issues/499.

We need this empty commit in order to re-run CI with the latest
https://github.com/flutter/tests.

Work in progress... currently testing against presubmit.

🫡

This was terribly outdated and has long been superseded by `package:flutter_lints`. Also, as of https://github.com/dart-lang/sdk/commit/c033718da0502ed92609f8c6cee2f6a59ccc058e support for this was removed from the analyzer and this file is now even more useless, if that's even possible.

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

Fixes https://github.com/flutter/flutter/issues/138227. Work towards https://github.com/flutter/flutter/issues/82948

In https://github.com/dart-lang/sdk/commit/c033718da0502ed92609f8c6cee2f6a59ccc058e, the analyzer's support for `analysis_options_user.yaml` is dropped. So no lint is reported in this test, as expected. This PR changes the test to expect no lint, and also no write the edits that trigger the lint.

Re-lands https://github.com/flutter/flutter/pull/137191.

The fix for the issue causing that PR to be reverted was tested in this PR but ultimately landed separately in https://github.com/flutter/flutter/pull/138093.

Pin the dependencies from dart-lang/native to a specific version during testing (rather than having them auto-upgrade during pub resolution). This will prevent tests using the template to start failing if a bad version is published to pub.

Closes: https://github.com/flutter/flutter/issues/137418

Also bumps dep in flutter_tools.

Reverts flutter/flutter#137191
Initiated by: camsim99
This change reverts the following previous change:
Original Description:
Adds support for Android 34 in the following ways:

- Bumps integration tests compile SDK versions 33 --> 34
- Bumps template compile SDK version 33 --> 34
- Also changes deprecated `compileSdkVersion` to `compileSdk`

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

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