* 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
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.
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#22530Fixes#22344
* Prototype
* Fix paths to Flutter library resources
* Invoke pod install as necessary for materialized modules
* Add devicelab test for module use on iOS
* Remove debug output
* Rebase, reame materialize editable
* Add devicelab test editable iOS host app
* Removed add2app test section
* Reland "Roll engine to version b148e628ec86b3a9a0382e0bcfae73f0390a8232 (#20427)"
This is a re-land with downgraded `package:flutter_gallery_assets`
version.
* Downgrade package:flutter_gallery_assets to 0.1.4
* Change engine.version to 81baff97c29bb08cbf8453a3f9042c5813f84ad3 (which contains an additional fix)
* Change engine.version to e3687f70c7ece72000b32ee1b3c02755ba5361ac (since mac tarballs are corrupted on earlier commit)
Reason for revert: The package:flutter_gallery_assets has removed some images which are required for the examples/flutter_gallery, so the gallery build is failing (only discovered after landing, since gallery doesn't seem to get built during github PR presubmit checks)
This CL
* rolls `engine.version` to flutter/engine@b148e628 (which includes dart sdk 2.1.0-dev)
* rolls `goldens.version` to flutter/goldens@6c45fafdf (which includes updates due to skia changes in engine)
* changes `platform.dill` to `platform_strong.dill` in various places due to flutter/engine@a84b210b
* adds explicit `environment: sdk: ">=2.0.0-dev.68 < 3.0.0"` constraints to `pubspec.yaml` and `pubspec.yaml.tmpl` files (since pub defaults to `<2.0.0` if omitted)
* upgrades to newer versions of various 3rd party packages (to ensure transitive dependencies have `<3.0.0` sdk constraint)
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.
