Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Regarding the missing CLA: I wanted to honor Emmanuel Garcia (blasten) in 965397c as he did the initial MR. Don't know how to circumvent this, without removing the contribution email.

See also: #129095 (comment)

Honestly I don't know how to reproduce the issue described in #98048, which was the reason why #97823 was reverted.

Based on the discussion there it involved having old versions of Gradle and/or AGP. The legacy app packages test might be helpful in trying to reproduce it.

So it may be fixed, comparing the old and the new settings.gradle.

Template updates can't fix a problem that is caused by the values that are in old templates, because once a project is instantiated it is generally not re-created. If thousands of projects (or more) in the wild still have a version that's incompatible with the change, then the change can't land without some kind of mitigation (e.g., a clear error message with instructions on updating).

Don't know how it's handled by the migration tool though.

The migration tool was not completed, and is not currently in development.

Regarding the missing CLA: I wanted to honor Emmanuel Garcia (blasten) in 965397c as he did the initial MR. Don't know how to circumvent this, without removing the contribution email.

It is far easier to remove the email from the authorship and just reference it in the PR than it is to bypass the CLA check (which requires one of a handful of people to go through a manual process).

Indeed I found the problem:
The mentioned settings.gradle is even older than the one used for testing legacy projects, see:

include ':app'

def flutterProjectRoot = rootProject.projectDir.parentFile.toPath()

def plugins = new Properties()
def pluginsFile = new File(flutterProjectRoot.toFile(), '.flutter-plugins')
if (pluginsFile.exists()) {
    pluginsFile.withReader('UTF-8') { reader -> plugins.load(reader) }
}

plugins.each { name, path ->
    def pluginDirectory = flutterProjectRoot.resolve(path).resolve('android').toFile()
    include ":$name"
    project(":$name").projectDir = pluginDirectory
}

And now the problem is more clear: Now plugins are also included from '.flutter-plugins', which do not have a android/build.gradle file, which were sorted out with the doesSupportAndroidPlatform method.

We could either:

• Drop support for this old version of settings.gradle file, as it isn't even used for testing against legacy project.
  • Write some warning, to upgrade the settings.gradle file (?)
• Just keep the check with doesSupportAndroidPlatform in the flutter.groovy file, which works also quite well, without compromises, but
  • Open a new issue, to describe the problem and link it in the code, also deprecate the doesSupportAndroidPlatform method.
  • Or even write a test to check this old settings.gradle file in a separate PR (e.g. for legacy projects), and if so, need this be done before this one?

Drop support for this old version of settings.gradle file, [...]

• Write some warning, to upgrade the settings.gradle file (?)

Anything that would drop support for old projects needs at least a warning, if not an automigration. We don't want people with old projects to suddenly be unable to compile without any idea why.

as it isn't even used for testing against legacy project.

The test I linked to is a specific legacy test based on the constraints of what was relatively straightforward to set up in the flutter/packages CI; it's not comprehensive or authoritative. We should not knowingly break people just because we haven't written a test that would fail in that scenario.

I now also replaced dependencyGraph with plugins as stated here.

And there were some tests regarding the legacy settings.gradle (#35217), but they were removed in #86911.

I added a test for the legacy settings.gradle but I think the other stuff such as gradle and agp version aren't compatible as it gives an error before actually running the code in settings.gradle.

Build file 'C:\Users\Gustl\AppData\Local\Temp\flutter_flutter_plugin_test.6be279f\test_plugin\example\android\app\build.gradle' line: 2

Plugin [id: 'com.android.application'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (plugin dependency must include a version number for this source)

Can I somehow use the legacy script flutter/packages/.ci/scripts/build_all_packages_app_legacy.sh ? Or should I add a test in the flutter/packages repository? Can you help me out on this one? I don't know what else to do... Thank you!

Can I somehow use the legacy script flutter/packages/.ci/scripts/build_all_packages_app_legacy.sh ? Or should I add a test in the flutter/packages repository?

flutter/packages tooling is not applicable in this repo, and any tests for changes here should be in this repo. I was just suggesting looking at that test as way to potentially reproduce the problem manually, as a starting point for figuring out how to reproduce it, and thus design a test for it.

I noticed the generate_gradle_lockfile tool was introduced, which changes the files I'm writing a test about. And every other test also uses the generated files since it was introduced. Even the gradle tests which are supposed to validate this old settings.gradle was updated (I think by accident) with #83067. I think these files testing old gradle stuff must be reverted then (?). And there should be added a possibility to exclude single files from the generate_gradle_lockfile tool or check these files don't change in an extra test (?)

This should now build successfully, but this does not help with #137040 at all, as it then loads all plugins as before and one cannot decide which plugin to load as long the plugins are imported using dependencyGraph from the .flutter-plugins-dependencies file. So settings.gradle needs to be migrated non the less (#54566), but only for such a case as #97729 (the other cases don't raise the problem). More explanation is here.

And what about the migration scripts here, can't we use them, to update non changed deprecated settings.gradle files?

Edit: I try now another solution, by explicitly excluding the packages which are not wanted, which can be easily determined.
Edit2: Exclusion after inclusion of plugins is not possible, but I now only use the old behavior (by adding non supported android plugins as API), if settings.gradle doesn't reference the .flutter-plugins file.

This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@stuartmorgan kindly asking for a review :)

The primary review here should be from someone on the Android team with more Gradle expertise.

Reverting due to #141940.

Time to revert pull request flutter/flutter/137115 has elapsed.
You need to open the revert manually and process as a regular pull request.