An optimization to the coverage collection speed was added in #30811. This commit further expands on it to parameterize the CoverageCollector with a custom predicate, allowing internal use cases to filter the RPC calls to the Dart VM based on scripts of interest to coverage collection.
`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
}
}
`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
}
}
Plus:
- Resume the app being run after expression has been evaluated to prevent the test run being forcefully terminated because it didn't end
- Skip non-JSON when waiting for JSON (eg. when running in verbose mode for debugging locally)
- Pass defaultTimeout in waitForJson (otherwise the assert in _timeoutWithMessages fails when it's not provided)
Closes https://github.com/flutter/flutter/issues/26518 (the original reason for skip was fixed in https://github.com/dart-lang/sdk/issues/34224).
When we were running `pub` within `flutter pub`, we were
unconditionally including the `--verbosity=warning` argument.
Then we were conditionally including `--verbose` if we were
running in verbose mode. However, the former argument
supersedes the latter, and we were never able to run `pub`
in verbose mode.
## Description
Instead of detaching from the spawned App process on the device immediately, keep the LLDB client connection open (in autopilot mode) until the App quits or the server connection is lost.
This replicates the behavior of Xcode, which also keeps a debugger attached to the App after launching it.
## Tests
This change will be covered by all running benchmarks (which are launched via "flutter run"/"flutter drive"), and probably be covered by all tests as well.
I also tested the workflow locally -- including cases where the App or Flutter CLI is terminated first.
## Breaking Change
I don't believe this should introduce any breaking changes. The LLDB client automatically exits when the app dies or the device is disconnected, so there shouldn't even be any user-visible changes to the behavior of the tool (besides the output of "-v").
This updates the flutter tool cache to download binary files for ideviceinstaller, ios-deploy, libimobiledevice, and dynamically linked dependencies from Flutter's GCP bucket.
This updates the flutter tool to cache binary files for ideviceinstaller, ios-deploy, libimobiledevice, and dynamically linked dependencies from Flutter's GCP bucket.
An upcoming change in the Dart SDK changes `Socket` from
implementing `Stream<List<int>>` to implementing `Stream<Uint8List>`.
This forwards-compatible change in flutter_tools prepares for that
Dart SDK change.
https://github.com/dart-lang/sdk/issues/36900
* Make it possible to override the FLUTTER_TEST env variable without unsetting it.
* Switch to using platform instead of Platform.
* Document the bindings, and introduce tests that initialize multiple WidgetsBindings with different environments.
* Add tests for the flutter platform test.
* Add license headers
* Fix lints
* Remove trailing whitespace
* Respond to Jonahs comments
* Respond to Ians comments
* Mock out the HttpServer in flutter_platform_test
* Mock out the HttpServer in flutter_platform_test
* Explain why we mock out the HttpServer in flutter_platform_test
