* Add smoke test for the new Android embedding
* Update AndroidManifest.xml in app template
* Update test README.md
* Remove widget_test.dart
* Update pubspec.yaml
* Force GeneratedPluginRegistrant.java
* Stop using build_runner for dart2js
* fixes to yield when computing hashes and to imports
* add missing await
* Update filecache_test.dart
* Fix paths in filecache test
* use file uri for import
* add test cases and configurable override
* remove test dep
* fix filepaths for windows
* test no longer failing
* fix paths for test cases
* fix typo
* address comments
* make a constant
* make filehash async and use constant
* fix silly logic error
Spawn no more than 1 iframe in web tests. Using multiple iframes in DDK mode times out tests. Also set concurrency to 1 to guarantee that the test runner does not even attempt to parallelize tests.
Before this change, having an Android app depend on a plugin that has no android implementation resulted in a Gradle build failure.
This scenario is likely to become more common if we're enabling federated plugins, as the package implementing just the desktop implementation of a plugin won't have an Android implementation.
This changes the Gradle plugin to not try to build any plugins that doesn't have an android/build.gradle file.
* WIP on web plugin registry
* WIP on registering plugins
* WIP on web plugin registration
* Only generate `package:flutter_web_plugins` imports if plugins are
defined
* Add parsing test
* Add documentation
* Fix analyzer warnings
* add license headers
* Add tests for package:flutter_web_plugins
* Run `flutter update-packages --force-upgrade`
* Fix analyzer errors
* Fix analyzer error in test
* Update copyright and remove flutter SDK constraints
* Enable tests since engine has rolled
* add flutter_web_plugins tests to bots
* Create an empty .packages file for WebFs test
Flutter widget tests assert if a test completes with timers still
pending. However, it can be hard to diagnose where a pending timer
came from. For example, a widget might consume a third-party library
that internally uses a timer.
I added a FakeAsync.pendingTimersDebugInfo getter to quiver
(https://github.com/google/quiver-dart/pull/500). Make flutter_test
use it.
Additionally modify Flutter's debugPrintStack to take an optional
StackTrace argument instead of always printing StackTrace.current.
Fixes#4237.
In another change (#37646), I want to test that a test fails and
prints expected output. I didn't see an existing way to do that, so
I modified `_runFlutterTest` and `runCommand` to allow capturing the
output. Currently capturing and printing output are mutually
exclusive since we don't need both.
Some awkward bits:
* There already exists a `runAndGetStdout` function that is very
similar to `runCommand`, and this change makes the conceptual
distinction more confusing.
* `runFlutterTest` has multiple code paths for different
configurations. I don't understand what the different paths are
for, and I added output checking only along one of them.
`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
}
}
This disables the Firebase Test Lab release smoke test, I think it's failing for reasons that probably don't have to do with the commit that started failing (which I think is dd51afd).
This is blocking autoroll of flutter/engine@b7b791b which fixes a TODAY bug: #36079
This adds a maintenance script that will allow us to "unpublish" a release: basically remove it from the cloud storage so that we're no longer serving it from the website.
Obviously, gsutil access to the cloud storage server is required for this to function.
* 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.
updates the regex the analyzer uses, so it should be able to recognize expressions such as
const Foo a = Foo(); as "other code" rather than a constructor call.
When we package Flutter, we used to find the "current" tag (which is the version number) by starting at the revision we are building on and looking backwards in time to find the most recent tag. This causes problems on release builds when we failed to tag properly.
This PR makes the packaging script be more strict by requiring the given revision to itself have a tag, but only when we're publishing the result. When we're not publishing the result, it's more lenient, since otherwise we couldn't test packaging on non-release commits.
I also renamed ProcessRunnerException to PreparePackageException, since we were using that exception more generally than just for processes.
* 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
## Description
Also update the existing dart files with missing licenses.
Without the fix, we'll emit the following error message
```
License headers cannot be found at the beginning of the following files.
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/lib/src/animation/tween_sequence.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/material/raw_material_button_test.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/async_lifecycle_test.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/sliver_constraints_test.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/app_test.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/test_border.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/physical_model_test.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/inherited_model.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter_tools/lib/src/base/user_messages.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter_tools/test/src/pubspec_schema.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter_tools/test/ios/simulators_test.dart
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
## Related Issues
Fixes https://github.com/flutter/flutter/issues/28368
## Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (`[x]`). This will ensure a smooth and quick review process.
- [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
- [x] My PR includes tests for *all* changed/updated/fixed behaviors (See [Test Coverage]).
- [x] All existing and new tests are passing.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] The analyzer (`flutter analyze --flutter-repo`) does not report any problems on my PR.
- [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I am willing to follow-up on review comments in a timely manner.
## Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?
- [ ] Yes, this is a breaking change (Please read [Handling breaking changes]).
- [x] No, this is *not* a breaking change.
<!-- Links -->
[issue database]: https://github.com/flutter/flutter/issues
[Contributor Guide]: https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Test Coverage]: https://github.com/flutter/flutter/wiki/Test-coverage-for-package%3Aflutter
[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/
[Handling breaking changes]: https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
Adds SHA256 checksums to the released package database, in preparation for showing them on the download website. (I'll update the existing data by hand).
Fixes#28465
This fixes the offline Dash/Zeal docs generation to use the newly added dartdoc markers for different entity types to make it more exact when finding entity names.
Bumped Dartdoc to the next release.
This converts all remaining "## Sample code" segments into snippets, and fixes
the snippet generator to handle multiple snippets in the same dartdoc block
properly.
I also generated, compiled, and ran each of the existing application samples,
and fixed them up to be more useful and/or just run without errors.
This PR fixes these problems with examples:
1. Switching tabs in a snippet now works if there is more than one snippet in
a single dartdoc block.
2. Generation of snippet code now works if there is more than one snippet.
3. Contrast of text and links in the code sample block has been improved to
recommended levels.
4. Added five new snippet templates, including a "freeform" template to make
it possible to show examples that need to change the app instantiation.
5. Fixed several examples to run properly, a couple by adding the "Scaffold"
widget to the template, a couple by just fixing their code.
6. Fixed visual look of some of the samples when they run by placing many
samples inside of a Scaffold.
7. In order to make it easier to run locally, changed the sample analyzer to
remove the contents of the supplied temp directory before running, since
having files that hang around is problematic (only a problem when running
locally with the `--temp` argument).
8. Added a `SampleCheckerException` class, and handle sample checking
exceptions more gracefully.
9. Deprecated the old "## Sample code" designation, and added enforcement for
the deprecation.
10. Removed unnecessary `new` from templates (although they never appeared in
the samples thanks to dartfmt, but still).
Fixes#26398Fixes#27411
Now the sample analyzer can be run locally with:
dart dev/bots/analyze-sample-code.dart --temp=/tmp/samples
And it leaves /tmp/samples around so you can take a look at the code that was generated to see if it's the artificial environment that the samples are evaluated in that is the culprit for a failed analysis.
Before, you had to specify the whole path to the dart executable, and had to modify the code to keep the tempdir around.
This changes the DocSetPlatformFamily key to be "dartlang" instead of the name of the package (usually "flutter"). This is so that the IntelliJ plugin for Dash will be able to go directly to the docs for a symbol from a keystroke, instead of needing to search all the docsets each time.
Without this, flutter isn't part of the list of package names it searches. After this, it finds the flutter docs because they're declared to be part of the "dartlang" family of docs.
Dashing doesn't have a way to configure this, so we modify the Info.plist directly to make the change.
This was causing analysis to fail when there was an import statement in a comment, such as when snippets add imports to their examples.
I narrowed the RegExp to match only those lines which aren't commented out, but it really should probably be using the analysis server to catch all cases (e.g. if someone put the doc comment into /** */ comments, it could still match). Since this is a Flutter-specific script, it's probably not worth doing that.
