Now that the new schema is supported on the stable channel, and the old
schema is considered legacy, the template should always create plugins
using the new schema.
Now that the new schema is supported on the stable channel, and the old
schema is considered legacy, the template should always create plugins
using the new schema.
* Update packages.
* Add many more global analyses.
* Catch trailing spaces and trailing newlines in all text files.
Before we were only checking newly added files, but that means we
missed some.
* Port the trailing spaces logic to work on Windows too.
* Correct all the files with trailing spaces and newlines.
* Refactor some of the dev/bots logic into a utils.dart library.
Notably, the "exit" and "print" shims for testing are now usable
from test.dart, analyze.dart, and run_command.dart.
* Add an "exitWithError" function that prints the red lines and
then exits. This is the preferred way to exit from test.dart,
analyze.dart, and run_command.dart.
* More consistency in the output of analyze.dart.
* Refactor analyze.dart to use the _allFiles file enumerating logic
more widely.
* Add some double-checking logic to the _allFiles logic to catch
cases where changes to that logic end up catching fewer files
than expected (helps prevent future false positives).
* Add a check to prevent new binary files from being added to
the repository. Grandfather in the binaries that we've already
added.
* Update all the dependencies (needed because we now import crypto in
dev/bots/analyze.dart).
* 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
This PR adds TargetPlatform.macOS to the TargetPlatform enum. This allows us to begin implementation of some adaptive UI based on which target platform is desired.
I haven't updated the tests here, that will come in a follow-up PR.
* 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
* Generate projects using the new Android embedding
* Add comment about usesNewEmbedding:true
* Feedback
* Rework way to detect new embedding in new apps
Adds macOS support for `flutter create`:
- Currently it is behind a hidden flag.
- Adds a TargetPlatform workaround to lib/main.dart in the standard app template when enabled.
- Supports `app` and `plugin`; `module` support doesn't yet exist for macOS in general.
This will eliminate the need to use FDE's examples as templates on macOS. The templates are based on the current state of FDE's examples, with templating support added (and with adoption of the new application delegate in the app, which hadn't been done yet in FDE, eliminating some boilerplate from the template).
Fixes#30703
`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
}
}
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 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.
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.
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.
Currently, in pubspec.yaml, semver.org is referred to for more about versioning.
However, the versionCode/versionName could differ on different platforms (iOS, Android, Dart).
This adds more clear and complete information that could help users to understand it better.
See: #27251
* move flutter_assets to App.framework
* Roll engine to 05fee4eeee0ff6b219b1fcc394371e5f6963cc46
05fee4eee Update default flutter_assets path for iOS embedding (flutter/engine#7518)
02205db01 Roll src/third_party/skia 5d052dac3ac1..02738a86e5fd (4 commits) (flutter/engine#7541)
af907c074 Roll src/third_party/skia 5c7a3ac0e214..5d052dac3ac1 (7 commits) (flutter/engine#7540)
dde286673 IWYU to get SkFontMetrics (flutter/engine#7539)
* Fix Podfile issue #24342
Sometimes base configurations (config.base_configuration_reference) can be nil, which leads to undefined method `real_path' for nil:NilClass.
* Disable bitcode in every case
Profile builds need access to sockets in order to launch the Dart
observatory server.
This permission used to be enabled by default in all build types,
but was moved to a build type specific manifest in
88b853f7eb
We hypothesize that many first-time users creating a new project will look at the README.md as a starting point for "what next". As we've updated our documentation particularly for new users, having better links to our codelabs and cookbooks will help them be productive.
* Use Xcode build configurations to drive Flutter build mode
* Proper check wrt local_engine, print error if profile mode misisng
* Remove unused code, update tests, fix template problem, update warning
* fix up warning
* add explanatory dev comment
* fix whitespace
* missing words, change lambda arrow to function body
* error indentation
* Test early exits for xcode_backend.sh
* only on macOS, use right test
* Update error messages
* case insensitive compare for build config
* Update gallery podfile
* update projects to add profile configuration
* make compatible with flavors
* add missing plist files
* add FLUTTER_FRAMEWORK_DIR back, set swift version for profile, tell Podfile about profile
* Use Xcode build configurations to drive Flutter build mode
* Proper check wrt local_engine, print error if profile mode misisng
* Remove unused code, update tests, fix template problem, update warning
* fix up warning
* add explanatory dev comment
* fix whitespace
* missing words, change lambda arrow to function body
* error indentation
* Test early exits for xcode_backend.sh
* only on macOS, use right test
* Update error messages
* case insensitive compare for build config
* Update gallery podfile
* update projects to add profile configuration
* make compatible with flavors
* add missing plist files
