Currently the state for our plugins is that

• the AGP version in the main plugin (some_plugin/android/build.gradle) and the example (some_plugin/example/android/build.gradle) frequently don't match, and
• plugins themselves almost never have a gradle-wrapper.properties (and thus Gradle version), but sometimes we accidentally end up with one, and if we do, the Gradle version there probably doesn't match either.

In practice, we have no commands in our tooling, and thus our CI, that run gradle commands directly against a plugin; it's always via the example using the gradlew created there by flutter. This means that the AGP version in the plugin's build.gradle doesn't actually mean anything useful. As an example, we recently landed a dependabot PR that updated a plugin's build.gradle to AGP 8, even though our CI doesn't even have a version of Java that supports AGP 8, and everything was fine.

To avoid confusion, we should have a tooling-enforced policy that keeps these in alignment:

• We should enforce that only examples have gradle-wrapper.properties files.
• We should either:
  • Enforce that all of the build.gradle files within a plugin packages match (and turn off dependabot management of AGP for non-example projects). The downside here is that all AGP dependabot PRs will require manually updating the other build.gradle file.
  • Have the example's AGP version reference a value defined in the main plugin's build.gradle, if such a thing is possible, such that updating one automatically makes the other use that value.

CC @reidbaker