Repository: flutter
Issue: The top-level `build.gradle` uses antipatterns
Labels: platform-android,tool,t: gradle,P2,team-android,triaged-android

This issue is somewhat of a sibling to #123934, but that issue is about the internal implementation of the Flutter Gradle Plugin. This one is about the template file that, upon `flutter create`, becomes `android/build.gradle`.

It is nothing very important, but IMHO, it's good to take note of this nonetheless. It can be useful to whoever might be working on Flutter x Gradle in the future.

## Description

Using [`subprojects`](https://docs.gradle.org/8.0.2/javadoc/org/gradle/api/Project.html#subprojects-groovy.lang.Closure-) and [`allprojects`](https://docs.gradle.org/8.0.2/javadoc/org/gradle/api/Project.html#allprojects-groovy.lang.Closure-) in Gradle build scripts is considered to be a rather [bad](https://github.com/gradle/gradle/issues/23255#issuecomment-1364039826) practice – it can lead to some problems and limitations in certain scenarios.


Excerpt from the [build.gradle file template for an app](https://github.com/flutter/flutter/blob/master/packages/flutter_tools/templates/app_shared/android-java.tmpl/build.gradle.tmpl):

```gradle
allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.buildDir = '../build'
subprojects {
    project.buildDir = "${rootProject.buildDir}/${project.name}"
}
subprojects {
    project.evaluationDependsOn(':app')
}
```

The `subprojects` in this snippet is reasonable and I don't know how we could get rid of it easily, but as for the `allprojects`, it's unneeded. I tested this by removing it in a few of my Flutter projects and nothing happened.

The `subprojects` and `allprojects` closures are used to apply configuration or tasks to all sub-projects or to all projects in a multi-project build. While this can be useful for applying common settings or tasks to multiple projects, it makes the buildscript less flexible.

One of the main drawbacks of using `subprojects` or `allprojects` is that it can limit the flexibility and customizability of individual sub-projects. If a sub-project needs to deviate from the common configuration or tasks, it may be difficult to do so without modifying the global build script. This can lead to conflicts and version control issues if multiple developers are working on the same build script.


### Possible alternative

So I'd suggest removing it, because plugins also declare these repositories. If the current behavior is to be kept, Gradle has a new feature for this - `dependencyResolutionManagement {}`:

> Instead of declaring repositories in every subproject of your build or via an allprojects block, Gradle offers a way to declare them in a central place for all project.
>
> Repositories used by convention by every subproject can be declared in the settings.gradle(.kts) file:

```gradle
dependencyResolutionManagement {
    repositories {
        mavenCentral()
        google()
    }
}
```

[Learn more here](https://docs.gradle.org/8.0.2/userguide/declaring_repositories.html#sub:centralized-repository-declaration) about this feature.

FWIW, Android Studio updated its templates to use `dependencyResolutionManagement` – [learn more here](https://stackoverflow.com/questions/70139843/why-is-no-allprojects-in-my-build-gradle-android-studio).