Make consistent use of gradle wrapper

[mravn-google]

• Flutter tooling now injects Gradle wrapper files into projects that do not have them. This helps prepare active projects for the Android Studio 3.0.0 release where Gradle and Android Gradle plugin versions will be bumped. It also allows us to build examples/ and dev/ apps with the Gradle wrapper without committing wrapper scripts and binaries to the Flutter repo.
• Flutter tool implementation no longer retrieves Gradle from user's Android Studio installation, but relies on the Gradle wrapper managed by the Flutter cache instead.
• examples/ and dev/ apps have been updated to match new project templates.

Fixes #9765.

[mit-mit]

lgtm, works great after the last commit

[Hixie]

IMHO the fact that we keep having to update our apps to match new templates (we do this frequently) suggests a fundamental problem with our approach. Things that should be under our control should be in our repo, not in our developer's repo. Things that should be under their control should not be things we should ever try to update.

[mravn-google]

@Hixie AFAIK, we have mostly been updating the apps in the Flutter repo to keep them close to what is generated by flutter create, that is, to avoid confusion, and not because they would not run otherwise. For instance, hello_world of Feb 28 still runs on Android with the present PR.

I agree it would be great to have a simple, operational rule to separate what should be in the Flutter repo and what should be in users' repos. Currently, we are not following a rule, but instead searching for a reasonable answer to the following set of design constraints and goals (partial list):

1. Flutter tooling must be able to build release apks/ipas.
2. Flutter tooling must support apps that aggregate plugins with platform-specific 3rd party dependencies, leveraging existing library eco systems.
3. Flutter tooling should not re-implement existing dependency management systems such as Gradle or Cocoapods.
4. Where possible, plugin consumption should be handled automatically by Flutter tooling; the user should just add a line to the pubspec.yaml file.
5. The android/ and ios/ folders of a Flutter project should look native to Android Studio and Xcode, and the Flutter app should be runnable from within those IDEs.
6. The examples/ should be immediately runnable by Flutter tooling upon repo download, and running should not leave dirty files as far as git is concerned.
7. The Flutter repo should not include binaries (those should be managed by the cache at tool run-time).

[Hixie]

8. Someone who wants to write Android-specific or iOS-specific code, e.g. embedding the FlutterView inside a wider Android app, needs to have a "real" app that follows conventions for those platforms.

It's #5 and #8 that make this particularly tricky, I think. If we didn't have #8, we could construct the android/ and ios/ directories on the fly in the build/ directory, but that wouldn't satisfy #8.

[jakobr-google]

LGTM

[jakobr-google]

We really shouldn't exclude the gradle wrapper files (including the .jar), if we want this to serve as an example of what an app should look like.

[mravn-google]

This is a clash between items 6 and 7 above.

[mravn-google]

I've added a comment to the .gitignore files explaining why they are excluded in the examples, and that it is not to be emulated.

[mit-mit]

@Hixie, note that 5./8. isn't only for writing specific code, or doing hybrid UI, it's also for the steps required to actually complete a release-version of an app. As you can see in https://flutter.io/android-release/ and https://flutter.io/ios-release/, that requires editing a number of files in the /android/ and /ios/ folders.

[mravn-google]

Fixes #10839

[runo280]

It seems you had removed the gradle-dir option, but I really need it, what should I do?