What's the plan to resolve #7504 ? We might want to fix that issue before we make this template the default because if we need to change anything in this file, we'll be stuck without a fix for #7504

This is a lot of boilerplate. Is there any way we can factor this out into code that's reused?

Having a lot of code here means:

• If we ever have to change it, we'll lose any users who have already created an app with the old template.
• Users will have all this code they don't understand and didn't write in their codebase, and will likely fiddle with it in ways that break them and we won't understand what's wrong.

If we keep this code we should document the heck out of it, like we do the default main.dart template.

Developers aren't supposed to edit this file. We should probably say that explicitly and have the build check that it hasn't been modified. (It's in a directory that developers normally don't expect to modify, but we should make that explicit.)

If we're not going to allow it to be modified, then we shouldn't include it in the template. We should just pull it in at build time.

(That would solve both problems above.)

We can try that, but I'm not sure it's possible. I think the way gradle works is that it uses shells scripts to bootstrap a java build of a tool that then builds your code. This is code that gets linked into the Java tool, and we don't want to mess with their shells scripts, so there might not be a way to jam it in later. Maybe it's possible to reference with some sort of path? It seemed to be using Java-style magic directories when I looked at it before.

I have a couple of ideas I'll try out, to see if we can consume the plugin from the flutter root. I'll let this PR sit in the meantime.

We presumably have to be able to hook into the build at some point, to build the Dart code and zip up the assets, for example. Can we provide the code at that point?

The FlutterPlugin is the code that hooks us into the build, by creating a FlutterTask (that builds the Dart code and zip up the assets), and wire up the dependencies in the build DAG. There are ways in Gradle to depend on external plugins by pointing at an artifact in a Maven repository, but we're special, so we need to tweak it a little.

I'm trying to avoid having flutter tools do too much other than invoke gradle at build time. Ideally, this should also work as a standalone Gradle project, so we can just open it in Android Studio and hit play, but it's probably fine to require an initial build using flutter tools that can set the path to the plugin correctly.

Can we put this code in a library that we then link to? We're not including all of the engine code, for example. Can this code belong there? That's what we've done on the iOS side.

Neat