* Update project.pbxproj files to say Flutter rather than Chromium
Also, the templates now have an empty organization so that we don't cause people to give their apps a Flutter copyright.
* Update the copyright notice checker to require a standard notice on all files
* Update copyrights on Dart files. (This was a mechanical commit.)
* Fix weird license headers on Dart files that deviate from our conventions; relicense Shrine.
Some were already marked "The Flutter Authors", not clear why. Their
dates have been normalized. Some were missing the blank line after the
license. Some were randomly different in trivial ways for no apparent
reason (e.g. missing the trailing period).
* Clean up the copyrights in non-Dart files. (Manual edits.)
Also, make sure templates don't have copyrights.
* Fix some more ORGANIZATIONNAMEs
* Generate projects using the new Android embedding
* Add comment about usesNewEmbedding:true
* Feedback
* Rework way to detect new embedding in new apps
Adds very preliminary support for Windows and Linux plugins:
- Adds those platforms to the new plugin schema, initially supporting just a plugin class.
- Adds C++ plugin registrant generation for any Windows or Linux plugins found.
This doesn't have yet have any build tooling for either platform, so anyone using the generated registrant still needs to do manual build configuration. This reduces the manual work, however, and creates a starting point for future tooling work.
As with all Windows and Linux work at this time, this is not final, and subject to change without warning in the future (e.g., Windows could potentially switch to a C# interface, or
'linux' may change to 'gtk' or 'linux_gtk' in pubspec.yaml).
Moves files generated in windows/flutter/ as part of the build to an ephemeral/ subdirectory, matching the approach used on macOS (and in the future, Windows).
Adds that directory to the generated properties file to minimize hard-coding of paths in the project.
* 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
We were using the `defaults` command-line utility to parse
Plist files, but it was never supported by Apple, and it
appears that in an upcoming OS release, it will be less likely
to work:
> WARNING: The defaults command will be changed in an upcoming
> major release to only operate on preferences domains. General
> plist manipulation utilities will be folded into a different
> command-line program.
Fixes https://github.com/flutter/flutter/issues/37701
`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
}
}
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.
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.
