[AGP 9] Support Enabling Built-in Kotlin#188543
Conversation
…stubbed in FlutterPluginTest as applying FGP happens much earlier in lifecycle
update to all projects have been evaluated
… createMockSubproject
…tead of hardcoding 8
…he flutter tooling. this value has to be adjusted manually
…no-log-agp-smoll-9
…not the major version.
…yle Guide compliance
There was a problem hiding this comment.
Code Review
This pull request refactors FlutterPluginUtils.kt to support the built-in Kotlin Gradle plugin configuration introduced in AGP 9.0+, extracting subproject plugin state scanning into a dedicated helper and adding helper methods to check if built-in Kotlin is enabled. Comprehensive unit tests are added to verify these changes. A critical review comment identifies that the early return logic in detectApplyingKotlinGradlePlugin causes redundant disk I/O by double-reading build files and introduces a correctness bug that force-applies legacy KGP to migrated subprojects if any single subproject still uses legacy KGP. The reviewer suggests removing the early return and guarding the plugin application directly inside the subprojects loop.
| val agpVersion = VersionFetcher.getAGPVersion(project) | ||
| if (isBuiltInKotlinEnabled(project, agpVersion) && hasNoSubprojectsApplyingKgp(project)) { | ||
| return | ||
| } |
There was a problem hiding this comment.
Correctness & Efficiency Issue: Double-reading of build files and incorrect logic
There are two significant issues with this early return:
-
Redundant Disk I/O (Efficiency):
hasNoSubprojectsApplyingKgp(project)scans and reads the build scripts of all subprojects. If it returnsfalse, the subsequent loop (project.rootProject.subprojects { ... }) will read all of those build scripts again. Disk I/O is slow, and doing it twice during the configuration phase can noticeably slow down Gradle configuration times for large multi-project builds. -
Correctness Bug (Critical): If
isBuiltInKotlinEnabledistruebuthasNoSubprojectsApplyingKgpisfalse(meaning at least one subproject still applies the legacy KGP), we do not return early. We then proceed to the loop where we callpluginManager.apply("kotlin-android")on every subproject that does not have KGP (!pluginState.hasKgpPlugin). This means we will force-apply the legacy KGP to all migrated subprojects, breaking their built-in Kotlin configuration!
Recommendation
Instead of checking hasNoSubprojectsApplyingKgp early, we should remove the early return entirely and simply guard the application of kotlin-android inside the loop with !isBuiltInKotlinEnabled. This avoids double-reading the build files and ensures we never apply kotlin-android to any subproject when built-in Kotlin is enabled.
val agpVersion = VersionFetcher.getAGPVersion(project)
val isBuiltInKotlin = isBuiltInKotlinEnabled(project, agpVersion)
var shouldLogForApp = false
project.rootProject.subprojects {
val pluginState = getSubprojectPluginState(this) ?: return@subprojects
// Ensures applying AGP exists in the build file configuration.
if (!pluginState.hasAppPlugin && !pluginState.hasLibPlugin) return@subprojects
if (!isBuiltInKotlin && !pluginState.hasKgpPlugin) {
try {
pluginManager.apply("kotlin-android")
} catch (_: Exception) {
project.logger.quiet(
"""
Applying the Kotlin Android Plugin (KGP) was unsuccessful. KGP was not found on the classpath.
If your project uses Kotlin, ensure KGP is declared in the root plugins block.
For more details check: $BUILT_IN_KOTLIN_DOCS
""".trimIndent()
)
}
}
// Apply AGP exists and Apply KGP also exists in build.gradle
if (pluginState.hasAppPlugin && pluginState.hasKgpPlugin) {
shouldLogForApp = true
}
if (pluginState.hasLibPlugin && pluginState.hasKgpPlugin) {
pluginsWithKGPAppliedList.add(name)
}
}
Added support for enabling built-in kotlin.
This branch was created off of:
jesswrd:no-log-agp-smoll-9from this PR here. Until that PR gets merged into master, the diff of this PR will remain ugly. I cannot diff/compare against a branch that does not exist in upstream flutter/flutter. Read a more readable diff here.Fixes #187712
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.