`flutter build aar`

This new build command works just like `flutter build apk` or `flutter build appbundle`, but for plugin and module projects.

This PR also refactors how plugins are included in app or module projects. By building the plugins as AARs, the Android Gradle plugin is able to use Jetifier to translate support libraries into AndroidX libraries for all the plugin's native code. Thus, reducing the error rate when using AndroidX in apps.

This change also allows to build modules as AARs, so developers can take these artifacts and distribute them along with the native host app without the need of the Flutter tool. This is a requirement for add to app.

`flutter build aar` generates POM artifacts (XML files) which contain metadata about the native dependencies used by the plugin. This allows Gradle to resolve dependencies at the app level. The result of this new build command is a single build/outputs/repo, the local repository that contains all the generated AARs and POM files.

In a Flutter app project, this local repo is used by the Flutter Gradle plugin to resolve the plugin dependencies. In add to app case, the developer needs to configure the local repo and the dependency manually in `build.gradle`:


repositories {
    maven {
        url "<path-to-flutter-module>build/host/outputs/repo"
    }
}

dependencies {
    implementation("<package-name>:flutter_<build-mode>:1.0@aar") {
       transitive = true
    }
}

This reverts commit 11460b83.

`flutter build aar`

This new build command works just like `flutter build apk` or `flutter build appbundle`, but for plugin and module projects.

This PR also refactors how plugins are included in app or module projects. By building the plugins as AARs, the Android Gradle plugin is able to use Jetifier to translate support libraries into AndroidX libraries for all the plugin's native code. Thus, reducing the error rate when using AndroidX in apps.

This change also allows to build modules as AARs, so developers can take these artifacts and distribute them along with the native host app without the need of the Flutter tool. This is a requirement for add to app.

`flutter build aar` generates POM artifacts (XML files) which contain metadata about the native dependencies used by the plugin. This allows Gradle to resolve dependencies at the app level. The result of this new build command is a single build/outputs/repo, the local repository that contains all the generated AARs and POM files.

In a Flutter app project, this local repo is used by the Flutter Gradle plugin to resolve the plugin dependencies. In add to app case, the developer needs to configure the local repo and the dependency manually in `build.gradle`:


repositories {
    maven {
        url "<path-to-flutter-module>build/host/outputs/repo"
    }
}

dependencies {
    implementation("<package-name>:flutter_<build-mode>:1.0@aar") {
       transitive = true
    }
}

Slight cleanup of file locations in flutter_tools
to make it easier to see which files are responsible
for data reporting.

This reverts commit 358b9bd3.

This is done via `flutter build bundle`.   As a consequence, this PR introduces a new way to disable analytics via the `FLUTTER_SUPPRESS_ANALYTICS` env flag.

* Gradle generates ELF shared libraries instead of AOT snapshots.
* `flutter build apk/appbundle` supports multiple `--target-platform` and defaults to `android-arm` and `android-arm64`.
* `flutter build apk` now has a flag called `--split-per-abi`.

Revert "Generate ELF shared libraries and allow multi-abi libs in APKs and App bundles (#33696)" (#34121)

* Gradle generates ELF shared libraries instead of AOT snapshots.
* `flutter build apk/appbundle` supports multiple `--target-platform` and defaults to `android-arm` and `android-arm64`.
*  `flutter build apk` now has a flag called `--split-per-abi`.

Use Dart's new direct ELF generator to package AOT blobs as shared libraries in Android APKs (#33611)

This is a replacement for the old implementation of --build-shared-library
that emits an AOT assembly snapshot and feeds it to the Android NDK toolchain.

Some parts of the appbundle build process were based on the logic for building
APK packages.  However, these steps (copying to a directory shared by all
build variants, and calculating a SHA) are not necessary for an appbundle.

* some space formattings

* always use blocks in if-else if a block is used

* format spaces in for and while

* allow multiline if conditions

* fix missing space

* add trailing commas on list/map/parameters

* add trailing commas on Invocation with nb of arg>1

* add commas for widget containing widgets

* add trailing commas if instantiation contains trailing comma

* revert bad change

* Allow for gradle downloading missing SDK assets if SDK licenses are present.

*  Improvements for windows testing

This reverts commit 6f5e88a5.

* Allow for gradle downloading missing SDK assets if SDK licenses are present.

* Fix license path for missing sdkmanager

* Cirrus re-run...

* Fix condition check

* rename props, add docs, rename method

* fix tests after param changes

* Fix weird path for flutter run and add tests

* remove print, fix tests

Revert "Add support for binary compression of dynamic patches by the flutter tool. (#27754)" (#28031)

This reverts commit b47da6c2.

This PR aims at several things:

1. Use pub_semver to check a version in pubspec.yaml meets the requirements specified in https://semver.org/.
2. Don't limit build-number/build-name as a fixed format. Instead, validate it according to the target(ios/android).
3. Make sure that build-number/build-name are always validated no matter it's specified by the `flutter command` or version in pubspec.yaml.

Fixes #27589

This reduces the typical dynamic patch size by more than 10x.

Also see https://github.com/flutter/engine/pull/7777 for decompression support in the runtime.

Try to detect Gradle error messages that hint at AndroidX problems, and
warn in the logs about the potential problem and point to documentation
on how to fix the issue.

Unfortunately the Gradle errors based on this root issue are varied and
project dependent. It's probably better to still leave the message
intact in case the problem is unrelated.

Also filters out the plugin warning message pending in
flutter/plugins#1138. It's still valuable to add that for people on
previous versions of Flutter, but this link should override that message
for anyone on an up to date version of Flutter.

#27106

* fix some bad indentations

* remove suspicious line

These are essentially self-inflicted race conditions. Instead of timeouts we're going to try a more verbose logging mechanism that points out when things are taking a long time.