- 11 Mar, 2020 1 commit
-
-
Emmanuel Garcia authored
-
- 13 Feb, 2020 1 commit
-
-
Dan Field authored
* drop unnecessary test deps * bump to junit 4.13
-
- 23 Jul, 2019 3 commits
-
-
Emmanuel Garcia authored
`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 } }
-
Emmanuel Garcia authored
This reverts commit 11460b83.
-
Emmanuel Garcia authored
`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 } }
-
- 01 Jun, 2019 1 commit
-
-
Josh Burton authored
-
- 19 Jan, 2019 1 commit
-
-
Dan Field authored
-
- 15 Jan, 2019 1 commit
-
-
Jason Simmons authored
Fixes https://github.com/flutter/flutter/issues/25703
-
- 10 Oct, 2018 1 commit
-
-
Greg Spencer authored
We decided that redefining the default for templates was premature. We're going to go back to having "module" in experimental land again, and we'll try again when we have the feature set fully baked. This keeps the writing of the .metadata files, and writing the template type to them, because that was a good improvement, and there are still a bunch of added tests that improve our coverage.
-
- 04 Oct, 2018 1 commit
-
-
Greg Spencer authored
This renames the "module" template to the "application" template, and makes "application" the default. The existing "app" template is now deprecated. flutter create also now recognizes the type of project in an existing directory, and is able to recreate it without having the template type explicitly specified (although you can still do that). It does this now by first looking in the .metadata file for the new project_type field, and if it doesn't find that, then it looks at the directory structure. Also, the .metadata file is now overwritten even on an existing directory so that 1) the project_type can be added to legacy projects, and 2) the version of Flutter that updated the project last is updated. I also cleaned up a bunch of things in create_test.dart, added many more tests, and added an example test to the test/ directory in the generated output of the application template. Fixes #22530 Fixes #22344
-
- 16 Aug, 2018 1 commit
-
-
Mikkel Nygaard Ravn authored
-
- 03 Aug, 2018 2 commits
-
-
Mikkel Nygaard Ravn authored
This reverts commit cacd291c.
-
Sarah Zakarias authored
-
- 28 Jul, 2018 1 commit
-
-
Greg Spencer authored
Fix the gradle templates so that they default to values rather than throw build exceptions. (#19916) When creating a new project, the build fails with an error similar to: "versionCode not found. Define flutter.versionCode in the local.properties file." This puts developers in the untenable situation of having to edit a file with local paths, but being unable to check it in. This changes the templates to default to using versionCode 1 and version "1.0" if they are not defined in the local.properties file. Fixes #18983.
-
- 28 Jun, 2018 1 commit
-
-
Mikkel Nygaard Ravn authored
-
- 22 Jun, 2018 1 commit
-
-
Mikkel Nygaard Ravn authored
-
- 01 Jun, 2018 1 commit
-
-
Mikkel Nygaard Ravn authored
-
- 31 May, 2018 2 commits
-
-
Mikkel Nygaard Ravn authored
This reverts commit 59bb2dba.
-
Mikkel Nygaard Ravn authored
-
- 30 May, 2018 1 commit
-
-
Ralph Bergmann authored
Uses the `version` property from the `pubspec.yaml` file to set the corresponding fields in the `local.properties` file respectively in the `Generated.xcconfig` file. The `--build-name` and `--build-number` options have changed. Now they trump the `version` property from the `pubspec.yaml` file. If the `version` property is not set and the `--build-name` and `--build-number` options are not provided, the build command will not change the `local.properties` / `Generated.xcconfig` file.
-
- 28 May, 2018 4 commits
-
-
Mikkel Nygaard Ravn authored
This reverts commit 0f557e72.
-
Mikkel Nygaard Ravn authored
-
Mikkel Nygaard Ravn authored
This reverts commit dac1baf4.
-
Mikkel Nygaard Ravn authored
-
- 08 Jan, 2018 2 commits
-
-
Jason Simmons authored
Fixes https://github.com/flutter/flutter/issues/13972
-
Mikkel Nygaard Ravn authored
-
- 14 Dec, 2017 1 commit
-
-
Mikkel Nygaard Ravn authored
-
- 13 Dec, 2017 1 commit
-
-
Mikkel Nygaard Ravn authored
-
- 29 Jun, 2017 1 commit
-
-
Mikkel Nygaard Ravn authored
-
- 20 Jun, 2017 1 commit
-
-
Michael Goderbauer authored
Going forward, Android support libraries are published on maven (instead of bundling them with the SDK). Many plugins depend on these. To avoid requiring plugin users to add the maven repository to their app this change adds the repository to the template for `flutter create`. This also bumps the support-annotations dependency to 25.4.0 (which also requires the new maven repository).
-
- 24 May, 2017 1 commit
-
-
Mikkel Nygaard Ravn authored
-
- 09 May, 2017 1 commit
-
-
Michael Thomsen authored
* Roll android build tools to 25.0.3 * Roll android build tools to 25.0.3 in templates
-
- 08 May, 2017 2 commits
-
-
Michael Thomsen authored
This reverts commit 5ed2984e.
-
Michael Thomsen authored
-
- 24 Apr, 2017 1 commit
-
-
Michael Thomsen authored
-
- 09 Mar, 2017 1 commit
-
-
Sarah Zakarias authored
* Add flutter_view sample * Removed platform_services files * Addressed comments * update README.md * Addressed comments.
-
- 28 Feb, 2017 1 commit
-
-
Michael Thomsen authored
-
- 21 Feb, 2017 1 commit
-
-
Michael Thomsen authored
-
- 10 Feb, 2017 1 commit
-
-
Jakob Andersen authored
* Make new project template gradle-based for Android. With this change, the 'new project' template uses the same gradle-based build for Android as the hello_services example. This has some implications on build performance, since we're now building a complete Android app instead of just combining a pre-compiled .dex with the Flutter assets. The very first build is a little over 2x slower, since it needs to download gradle and build the build scripts before getting to the actual code. Subsequent builds with changes to the code are comparable to the old builds. Null builds are faster. Enabling the gradle daemon speeds up subsequent builds by around 5s. * Move Flutter Gradle plugin to Flutter root.
-
- 31 Jan, 2017 1 commit
-
-
Jakob Andersen authored
* Update gradle example to support x86 in debug mode. Changed the Flutter Gradle plugin a bit to better fit in with the Android build. Fixes #6136 Fixes #6864 Fixes #7539
-