It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie or stuartmorgan on the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!).

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.

@reidbaker Are you the right person to review or do you have a suggestion for someone else who could take a look?

Note, proguard changes are hard to debug and this will silently apply to all users. We should make sure to pay attention to reports from users if they update flutter and run into proguard configuration issues.

Also this should be listed in our release notes for the next version.

Thanks for adding this change btw, for most users this should be a win.

Note, proguard changes are hard to debug and this will silently apply to all users. We should make sure to pay attention to reports from users if they update flutter and run into proguard configuration issues.

Very true, some plugins and apps will run into trouble with this.

But users of apps/plugins can then craft the right proguard rules or opt-out entirely again by using the unoptimized android config via updating android/app/build.gradle:

android {
    ...
    buildTypes {
        release {
            ...
+            proguardFiles(
+                getDefaultProguardFile("proguard-android.txt"),
+            )
        }
    }
}

Though if we don't do this here, we basically prevent all apps from being optimized and make them unnecessarily big. That seems a very poor choice - especially given that app size is a focus for many users (and our teams).

@reidbaker I couldn't find a CHANGELOG.md. How do we ensure we mention this in the release notes? (I've added some context to the commit message 1dd21f8 that could be used)

After some debugging by @gmackall, it looks like this PR caused a failure in the flutter/flutter --> flutter/packages roll (example build failure: https://ci.chromium.org/ui/p/flutter/builders/try/Linux_android%20android_build_all_packages%20master/3395/overview from flutter/packages#5247). There are a couple of different errors, but the error causing the failure is:

ERROR:/b/s/w/ir/cache/gradle/caches/transforms-3/0bb06dfe4da25affb101e8419c105cae/transformed/jetified-exoplayer-dash-2.18.7-runtime.jar: R8: com.android.tools.r8.internal.Y10: Unused argument with users in com.google.android.exoplayer2.source.dash.manifest.DashManifest com.google.android.exoplayer2.source.dash.manifest.DashManifestParser.parseMediaPresentationDescription(org.xmlpull.v1.XmlPullParser, android.net.Uri)

But we also see a failure indicating that the Kotlin Gradle Plugin version of Flutter apps would need to be increased to accomodate this change as well:

e: /b/s/w/ir/cache/gradle/caches/transforms-3/d8631146b770a211a2a1c562a0507fce/transformed/fragment-1.6.1/jars/classes.jar!/META-INF/fragment_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/transforms-3/329c2bfac2a7dae481a23d2359827e09/transformed/jetified-activity-1.7.2/jars/classes.jar!/META-INF/activity_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/transforms-3/72a3680227e5f4d2b1d13d9db0b65277/transformed/lifecycle-livedata-2.6.1/jars/classes.jar!/META-INF/lifecycle-livedata_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/transforms-3/a4bada2f199602af9d6709404cc351a6/transformed/lifecycle-viewmodel-2.6.1/jars/classes.jar!/META-INF/lifecycle-viewmodel_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/transforms-3/d99d8757de67c6d3fc133f42b65e3a90/transformed/lifecycle-livedata-core-2.6.1/jars/classes.jar!/META-INF/lifecycle-livedata-core_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/transforms-3/84b80648e9636f752965ad11a42400ed/transformed/jetified-lifecycle-viewmodel-savedstate-2.6.1/jars/classes.jar!/META-INF/lifecycle-viewmodel-savedstate_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/transforms-3/3c43b230d6865a9c7118f435542945e5/transformed/jetified-core-ktx-1.10.1/jars/classes.jar!/META-INF/core-ktx_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/transforms-3/ebe576e2716bc3721ebe4c0c07c623cc/transformed/core-1.10.1/jars/classes.jar!/META-INF/core_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/transforms-3/d1046fc82f6ddb1aaf84523b7aa19cd0/transformed/lifecycle-runtime-2.6.1/jars/classes.jar!/META-INF/lifecycle-runtime_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/modules-2/files-2.1/androidx.lifecycle/lifecycle-common/2.6.1/10f354fdb64868baecd67128560c5a0d6312c495/lifecycle-common-2.6.1.jar!/META-INF/lifecycle-common.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/transforms-3/4c09017685166a615568443628405865/transformed/jetified-savedstate-1.2.1/jars/classes.jar!/META-INF/savedstate_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.8.22/636bf8b320e7627482771bbac9ed7246773c02bd/kotlin-stdlib-1.8.22.jar!/META-INF/kotlin-stdlib-jdk7.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.8.22/636bf8b320e7627482771bbac9ed7246773c02bd/kotlin-stdlib-1.8.22.jar!/META-INF/kotlin-stdlib.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.8.22/636bf8b320e7627482771bbac9ed7246773c02bd/kotlin-stdlib-1.8.22.jar!/META-INF/kotlin-stdlib-jdk8.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /b/s/w/ir/cache/gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-common/1.8.22/1a8e3601703ae14bb58757ea6b2d8e8e5935a586/kotlin-stdlib-common-1.8.22.jar!/META-INF/kotlin-stdlib-common.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0

@mkustermann @reidbaker Reverting this PR for now, let us know if we can help provide any further context!

There are a couple of different errors, but the error causing the failure is:

Looking at R8 code it seems like an Unreachable exception being thrown, indicating a bug in Android's R8 dexer/shrinker. I'll follow up with the R8 team on this.

But we also see a failure indicating that the Kotlin Gradle Plugin version of Flutter apps would need to be increased to accomodate this change as well:

@reidbaker Is the Kotlin Gradle Plugin backwards compatible? (seems like minor version update to kotlin metadata format - i.e. backwards compatible) If so maybe we can update that plugin?

We have run into downstream effects when bumping other dependencies that also depend on the kotlin library. Something about duplicate class definitions if customer apps use an old version of kotlin. Which most do because it is in our templates.

Looking at R8 code it seems like an Unreachable exception being thrown, indicating a bug in Android's R8 dexer/shrinker. I'll follow up with the R8 team on this.

The R8 team confirmed this. Seems like the bug has been seemingly fixed for over a year. The reason we run into this bug is because the flutter project uses an old android gradle plugin (i.e. nothing to do with kotlin gradle plugin version) - because R8 is shipped as part of android gradle plugin.

After some debugging by @gmackall, it looks like this PR caused a failure in the flutter/flutter --> flutter/packages roll, ...

So to reproduce the failure one has to do roughly this:

# Checkout flutter/flutter & reset to commit that changed to optimized proguard rules
% git clone https://github.com/flutter/flutter ~/myflutter && cd ~/myflutter
~/myflutter % git reset --hard 1dd21f8d996f233ed0b8aeb8451d16d9df783f39

# Ensure we use this flutter version
% export PATH=$HOME/myflutter/bin:$PATH

# Checkout flutter/packages
% git clone https://github.com/flutter/packages ~/flutter-packages && cd ~/flutter-packages

# Repro steps from the CI bot:

~/flutter-packages % flutter update-packages
...
~/flutter-packages % $PWD/.ci/scripts/prepare_tool.sh  
...
~/flutter-packages % $PWD/.ci/scripts/create_all_packages_app.sh
...
~/flutter-packages % $PWD/.ci/scripts/build_all_packages_app.sh apk release

Running flutter build apk --release inside ~/flutter-packages/all_packages is the same as the last step.

The way one can fix this is to basically upgrading the android gradle plugin, which for me required:

# Ensure we use Java 17 version
% vim android/gradle.properties
org.gradle.java.home=/usr/lib/jvm/java-17-openjdk-amd64/

# Update gradle wrapper from 7.x to 8.0
% vim android/gradle/wrapper/gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-all.zip

# Update gradle plugin version from 7.x to 8.1.0
% vim android/settings.gradle
plugins {
      id "com.android.application" version "8.1.0" apply false
}

(There's no need to update ext.kotlin_version in android/build.gradle)

We have run into downstream effects when bumping other dependencies that also depend on the kotlin library. Something about duplicate class definitions if customer apps use an old version of kotlin. Which most do because it is in our templates.

It seems like a big problem if we generate templates with hard-coded versions in them and users don't upgrade. It makes user's apps have old gradle android plugin, which makes users not get bugfixes / performance improvements, ...

It also seems problematic because users old gradle deps depend on newest flutter gradle plugin, so the flutter gradle plugin has to operate in an environment of old deps itself as well.

@reidbaker Is there a plan forward how to get our users onto the latest versions? Or is the solution here to just update the android gradle plugin for our CI and re-land this change?

Getting users to update versions of software we don't ship is a constant struggle. We have a few patterns for helping users here. Sometimes we print build warnings and sometimes for things that we know will break we will do auto migrations. Specifically for agp we have been building tooling that evaluates incompatibilitys with other dependencies since that can be hard for flutter users to figure out. Also there is active work to set a minimum ago version for flutter projects.

That said the bulk of your concern is valid. We generate a lot of versions in our template files and do not and for many can not have a good way to update them automatically since they are project level files and changing the values for existing projects can cause breakages or bugs.

To clarify: To make this PR re-land without causing the flutter/packages CI bot failure I was made aware of, the only change needed seems to change the flutter create template code to produce files with newest gradle/AGP:

diff --git a/packages/flutter_tools/lib/src/android/gradle_utils.dart b/packages/flutter_tools/lib/src/android/gradle_utils.dart
index 14a3d1462b..3145fea00a 100644
--- a/packages/flutter_tools/lib/src/android/gradle_utils.dart
+++ b/packages/flutter_tools/lib/src/android/gradle_utils.dart
@@ -26,8 +26,8 @@ import 'android_sdk.dart';
 // However, this currently requires to migrate existing integration tests to the latest supported values.
 //
 // Please see the README before changing any of these values.
-const String templateDefaultGradleVersion = '7.5';
-const String templateAndroidGradlePluginVersion = '7.3.0';
+const String templateDefaultGradleVersion = '8.0';
+const String templateAndroidGradlePluginVersion = '8.1.0';
 const String templateAndroidGradlePluginVersionForModule = '7.3.0';
 const String templateKotlinGradlePluginVersion = '1.7.10';

Following up on this because there has been more discussion, I think this would be a good change that we should try to re-land. The error message for the bad AGP versions is unfortunately a bit opaque, though, and made more so by the fact that we are handling the definition of the proguard file. So it would be significantly harder for a flutter developer to identify this root cause without knowledge of the inner workings of the flutter gradle plugin.

Concrete things that could be added that would make me comfortable with landing:

1. An addition to gradle_errors.dart identifying this exact error, and telling the flutter developer that this is due to their AGP version, where/how to change their AGP version, which AGP versions are impacted
2. I wouldn't want to land a change that makes the template AGP version be one that doesn't work. flutter create -> flutter build apk should always work. So we would want to change the template AGP version ahead of the PR, or in the PR itself.
3. A short notice in the technical blog for when the change hits stable, to give people a heads up.

@gmackall Sounds promising. Who would be a good owner for this?