It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

Thought

The benefit of using Gradle lockfiles is not documented anywhere on Flutter's website. I think it should be – I can imagine large scale apps want to have as reproducible builds as possible, but without using Gradle lockfiles, there's no guarantee of this (for Android build of their Flutter app).

It wouldn't have to be a long doc, here's a draft.

Improve reproducibility of your Android builds by enabling Gradle dependency locking

Your pub dependencies (and all their transitive dependencies) are already pinned to specific versions in the pubspec.lock file. Unfortunately, because Flutter is multiplatform, it uses many build systems. This makes achieving reproducible builds more involved than simply relying on pubspec.lock.

To improve the reproducibility of Android builds of your Flutter app, we recommend using Gradle dependency locking (sometimes called "Gradle lockfiles").

If you're already using concrete versions for all your dependencies in build.gradle (e.g., specifying exact versions like 8.7.3), Gradle lockfiles might seem redundant at first glance, but they can still serve a purpose.

• The Gradle buildscripts of Android implementation of Flutter plugins you depend on may specify exact versions of dependencies. But you don't know if the plugins' transitive dependencies also do this, or if they misbehave and use dynamic version ranges. In such case, having a lockfile is the best way to ensure you always resolve to exactly the same dependency tree (unless you explicitly update the lockfiles).

Enable Gradle dependency locking in your app

In android/settings.gradle[.kts], add the following code:

// ...

+buildscript {
+    dependencyLocking {
+        lockFile = file("${rootProject.projectDir}/buildscript-gradle.lockfile")
+        lockAllConfigurations()
+    }
+}

plugins {
    id("dev.flutter.flutter-plugin-loader")
    // ...

In android/build.gradle[.kts], add the following code:

subprojects {
    project.evaluationDependsOn(":app")
+    dependencyLocking {
+        ignoredDependencies.add("io.flutter:*")
+        lockFile = file("${rootProject.projectDir}/project-${project.name}.lockfile")
+        if (!project.hasProperty("local-engine-repo")) {
+            lockAllConfigurations()
+        }
+    }
}

Now run ./gradlew :generateLockfiles in the android directory. To update the lockfiles, run this task again.