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
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.
AOT compiled code is now packaged as an ELF library for Android targets.
By default gen_snapshot's output contains debug symbols. The symbols could
be stripped as a separate step, but that requires NDK tools that the user
may not have available.
This change passes a gen_snapshot flag that omits the symbols, and it filters
out a warning printed when that flag is used.
Updates the Podfile template to use the CocoaPod disable_input_output_paths installation option which prevents the [CP] Embed Pods Frameworks build phase from outputting the Flutter.framework files.
* 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`.
* 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`.
Adds two new custom analytics dimensions: run_target_os_version and run_target_mode_name that are sent with each invocation of flutter run and show up in Google Analytics as "screens".
Instead of sharing the iOS codepath that uses an ObjC generated plugin
registrant and expecting plugins to have an ObjC interface layer, switch
to generating a Swift registrant and expecting plugins to have a Swift
interface.
This means plugins on macOS that use Swift won't need an ObjC wrapper,
and plugins that use ObjC will need a Swift wrapper (inverting the
structure relative to iOS).
Moves the logic for finding vcvars64.bat to a new VisualStudio class
that encapsulates finding, and providing information about, VisualStudio
installations. Adds a validator for it, and runs it for Windows
workflows in doctor.
This wasn't included originally since it didn't seem to be necessary for
macOS in testing, but not having it breaks Swift plugins. This matches
the iOS Swift Podfile template.
Updates the Podfile template to use the CocoaPod disable_input_output_paths installation option which prevents the [CP] Embed Pods Frameworks build phase from outputting the Flutter.framework files.
This implements the keyboard shortcut handling and action invocation in order to provide a place in the infrastructure for keyboard events to trigger actions. This will allow binding of key events to actions like "move the focus to the next widget" and "activate button".
Updates the Podfile template to use the CocoaPod disable_input_output_paths installation option which prevents the [CP] Embed Pods Frameworks build phase from outputting the Flutter.framework files.
In runTests, we previously now default the optional boolean `web`
parameter to false to ensure (or at least improve the odds) that the
conditional on line 70 evaluates to true or false.
Enables the CocoaPods-based plugin workflow for macOS. This allows a
macOS project to automatically fetch and add native plugin
implementations via CocoaPods for anything in pubspec.yaml, as is done
on iOS.
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.
Rather than macos/Flutter containing a mixture of files that should and
shouldn't be checked in, create clear locations for:
- Files that are "owned" by Flutter, but should be checked in
(Flutter/). This will contain files like the top-level Flutter
xcconfigs, generated plugin registrants, etc.
- Files that are generated by Flutter on the fly, and should not be
checked in (Flutter/ephemeral/). This will contain Flutter SDK caches,
the generated xcconfig, etc.
Also adds Flutter-owned Debug and Release xcconfig variants, in
preparation for PodSpec tooling.
Rather than hard-coding a set of locations to check, use vswhere (which
is installed by VS 2017 and later), and construct the vcvars64.bat path
relative to that. This will allow Windows builds to work without special
configuration for people who have VS installed at a custom path.
Also adds error logging with different messages for each failure point,
so that rather than the not-very-informative 'failed to find
vcvars64.bat' message, the failure will provide feedback about what to
do.
This is an interim solution; later this will be replaced by a
VisualStudio class with associated validator to match the structure of
the other toolchains.
Fixes#33249
Invoking msbuild with runInShell makes handling path escaping more
error-prone, and substantially increases the chances of running into
maximum path limits. This replaces the direct call with a .bat wrapper
that calls vsvars64.bat then msbuild, and uses relative paths within the
script to keep command lengths short.
Fixes https://github.com/flutter/flutter/issues/32792
Splits Xcode validation out of the iOS validator and into a stand-alone
validator, and groups the CocoaPods validator with that top-level
validator instead of the iOS validator. iOS now validates only the
iOS-specific tools (e.g., ideviceinstaller).
Reorganizes many of the associated clases so that those that are used by
both macOS and iOS live in macos/ rather than ios/. Moves some
validators to their own files as part of the restructuring.
This is the macOS portion of #31368
Updates documentation and non-public API to use American spellings for
consistency with the rest of the codebase.
No changes to behaviour... other than how it's spelt.
Adds a new macosPrefix, which serves the same purpose as iosPrefix but
for macOS plugins.
It is not yet used by the tooling, but this allows for plugins to start
to be written using it in preparation for tooling support for plugins.
Part of #32718
* Clean up some flutter_tools tests
* Remove arbitrary retry that happens even for fundamental errors, and generally clean up _DevFSHttpWriter.
* Update dependencies (requires fixes; see next commit)
* Fixes for new dependencies.
Instead of requiring a name_output.sh, expect a file called
.app_filename in the macos/Flutter directory containing just the name of
the application. The expectation is that the Xcode build will create
that file with a script.
This is not intended as a long-term solution, but it's a substantial
improvement over name_output.sh:
- name_output.sh required constructing the full build output path; this
made sense when it was coupled with build.sh, but now that the
decision for where build output goes lives in flutter_tool, that logic
should as well.
- Changing the name of the application required also updating
name_output.sh, which is error-prone. With .app_filename, it can be
created using $PRODUCT_NAME, which means that the usual way of setting
the application name will automatically update this flow as well.
Part of #30706
Allows Windows builds to use the same structure and script as Linux
builds now use, calling into tool_backend to manage copying resources to
the project directory and building the bundle.
Also switches from expecting name_update.bat to expecting flutter\exe_filename
to be written during the build, as with the recent changes to the macOS build, to
reduce the amount of boilerplate needed in a windows\ project directory.
This implements focus and hover handling for Material buttons. It inserts Focus widgets into the tree in order to allow buttons to be focusable via keyboard traversal (a.k.a. TAB traversal), and Listener widgets into the InkWell to allow the detection of hover states for widgets.
Addresses #11344, #1608, and #13264.
Eliminates the need for a build.bat in the Windows build workflow, adding
preliminary support for building using msbuild. The handling of
vcvars64.bat may be refined in the future, but this serves as a starting point.
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.
- Removes SYMROOT from the Generated.xcconfig. Having it causes current
versions of Xcode to switch the project's build output to "Legacy",
which causes anything not overridden to use a project-relative build
directory instead of a shared directory in DerivedData, breaking
anything with subprojects that it depends on.
This means that `flutter run` and builds from Xcode will use
completely different build directories, but that each should be
internally consistent.
- Moves the FlutterMacOS.framework to $SRCROOT/Flutter. This is
consistent with the approach we're moving to for all desktop
platforms, and avoids issues finding it now that SYMROOT doesn't match
for the two different build modes.
Fixes#32494
This is the correct metric to report for compilation time benchmarks rather
than RunTime. Rename the 'gen_snapshot' value to merely 'snapshot' for
backwards compatibility and overall simplicity.
This change simplifies Dart's benchmarking of Flutter by making it easier to
adopt --report-timings (made for Dart to use), which makes the benchmarks
much more robust.
