[Android] Adds namespace to module build file templates

[camsim99]

Adds namespace to module build.gradle file templates.

Fixes #126403.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

[camsim99]

Looks like some tests are failing because they need multidex support. Not sure how they are related but I can update this PR

[vbuberen]

I am bit late to this PR, but curios why the template for the new project needs a check for compatibility with AGP < 4.2? It is not some plugin and there is no need to have such compatibility. Even if the template is used to create a module for existing Android app as mentioned in the issue, Android devs tend to keep their projects up to date better than Flutter ones and definitely won't use such old versions of AGP as pre-4.2.

[stuartmorgan]

It is not some plugin

It is a module, which means it's intended for use in projects we don't directly control, so has the same fundamental compatibility concerns.

Android devs tend to keep their projects up to date better than Flutter ones and definitely won't use such old versions of AGP as pre-4.2.

Do you have metrics showing that nobody using the module build has a project with AGP 4.1?

[vbuberen]

It is a module, which means it's intended for use in projects we don't directly control, so has the same fundamental compatibility concerns.

We already had this discussion with you in Plus Plugins, so don't want to continue and would prefer to agree that we disagree here on this topic.

Do you have metrics showing that nobody using the module build has a project with AGP 4.1?

I didn't say nobody. No, I don't have such metric, but it is something that you can get from the team responsible for releases of AGP as they might have such info. But as Android developer I know that sticking to old AGP in your project means that you consciously not using the latest optimisations for builds and new features. Also, build.gradle of your Android project is the same things as pubspec.yaml for Flutter devs and Android devs update dependencies there, including AGP (which is also updated with every release of Android Studio). In any of Android native projects I consulted or worked on I have seen build.gradle having AGP version older than 1 year. 4.2 is already 2 years old, thus, people with < 4.2 using something really old and it is hard to call a maintained project.

[reidbaker]

It is a module, which means it's intended for use in projects we don't directly control, so has the same fundamental compatibility concerns.

We already had this discussion with you in Plus Plugins, so don't want to continue and would prefer to agree that we disagree here on this topic.

Do you have metrics showing that nobody using the module build has a project with AGP 4.1?

I didn't say nobody. No, I don't have such metric, but it is something that you can get from the team responsible for releases of AGP as they might have such info. But as Android developer I know that sticking to old AGP in your project means that you consciously not using the latest optimisations for builds and new features. Also, build.gradle of your Android project is the same things as pubspec.yaml for Flutter devs and Android devs update dependencies there, including AGP (which is also updated with every release of Android Studio). In any of Android native projects I consulted or worked on I have seen build.gradle having AGP version older than 1 year. 4.2 is already 2 years old, thus, people with < 4.2 using something really old and it is hard to call a maintained project.

Thank you for your engagement and concern for flutter. In this case there are 2 reasons why I encouraged @camsim99 to include agp 4.1 backwards compatibility. First is that we know about the compatibility issue and to keep compatibility is safe, easy to maintain, and straightforward to maintain. That alone would be a good reason for writing compatible code. The second is that flutter support many kinds of developers. Educational use including students and teachers, side projects, ios/mac/windows only developers that want to run on android and developers that maintain dozens or hundreds of apps which may or may not ever be published by any app store. As a philosophy we try to make it easy for all kinds of developers to adopt new versions of flutter, new versions of packages and build new apps with the least amount of manual maintenance as we can get away with.

So for this cl compatibility is in the spirit/philosophy of the flutter project.