`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.
* Fall back to ANDROID_SDK_ROOT if ANDROID_HOME is not set
And update descriptions to use the non-deprecated ANDROID_SDK_ROOT.
Fixes#15114.
* Remove trailing whitespace
* Update dev/devicelab/lib/framework/adb.dart
Co-Authored-By: DanTup <danny@tuppeny.com>
* Reformat long line
* Allow snippets tool to be run from arbitrary CWDs
* Drop use of absolute when using Platform.executable (path is not relative, might require PATH resolution)
* canonicalize paths
* Use path.fromUri consistently to resolve file URIs
* Force commit to try to kick Cirrus
* Force commit to kick Cirrus, again
This sets the favicon for the offline Dash/Zeal docs.
Also, sets up the OpenSearch Description metadata file so that people can create custom search shortcuts for the API docs site.
Fixes#6412
