[CP-beta]Revert "Resolve resolve native Flutter dependencies in Android Studio (#167332)" #177255
Conversation
…flutter#167332)" (flutter#177053) This reverts commit 0c0406a. Fixes flutter#177037 I am leaving the method for checking if the build was launched from android studio. ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [ ] I updated/added relevant documentation (doc comments with `///`). - [ ] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing.
|
@reidbaker please fill out the PR description above, afterwards the release team will review this request. |
|
This pull request was opened from and to a release candidate branch. This should only be done as part of the official Flutter release process. If you are attempting to make a regular contribution to the Flutter project, please close this PR and follow the instructions at Tree Hygiene for detailed instructions on contributing to Flutter. Reviewers: Use caution before merging pull requests to release branches. Ensure the proper procedure has been followed. |
There was a problem hiding this comment.
Code Review
This pull request reverts a previous change related to resolving native Flutter dependencies in Android Studio. The modifications remove the maybeAddAndroidStudioNativeConfiguration function and its related helpers, which were responsible for adding compileOnly dependencies. Additionally, a try-catch block surrounding the generateLockfiles task registration in FlutterPlugin.kt is removed.
| rootProject.tasks.register("generateLockfiles") { | ||
| doLast { | ||
| rootProject.subprojects.forEach { subproject -> | ||
| val gradlew: String = | ||
| getExecutableNameForPlatform("${rootProject.projectDir}/gradlew") | ||
| val execOps = rootProject.serviceOf<ExecOperations>() | ||
| execOps.exec { | ||
| workingDir(rootProject.projectDir) | ||
| executable(gradlew) | ||
| args(":${subproject.name}:dependencies", "--write-locks") | ||
| } | ||
| } | ||
| } | ||
| } catch (e: TaskInstantiationException) { | ||
| // ignored | ||
| } |
There was a problem hiding this comment.
This revert removes the try-catch block that was added to prevent a crash when the generateLockfiles task is already registered. This can happen if addTaskForLockfileGeneration is invoked multiple times on the same root project. Reverting this could reintroduce build failures.
A safer way to handle this is to check for the task's existence before registering it, which is better than catching and ignoring an exception.
Consider using findByName to ensure idempotency:
if (rootProject.tasks.findByName("generateLockfiles") == null) {
rootProject.tasks.register("generateLockfiles") {
doLast {
rootProject.subprojects.forEach { subproject ->
val gradlew: String =
getExecutableNameForPlatform("${rootProject.projectDir}/gradlew")
val execOps = rootProject.serviceOf<ExecOperations>()
execOps.exec {
workingDir(rootProject.projectDir)
executable(gradlew)
args(":${subproject.name}:dependencies", "--write-locks")
}
}
}
}
}6c0f1cf
into
flutter:flutter-3.37-candidate.0
|
@reidbaker Late catch but this should be to flutter-3.38.candidate.0. Can you make another cherry pick? |
Requesting a review from a release engineer who is not me and a review from the flutter android team that is not me.
Issue Link:
What is the link to the issue this cherry-pick is addressing?
#177037
Changelog Description:
flutter/issue/177037 Allows some android apps that use dynamic modules to build from android studio.
Workaround:
Is there a workaround for this issue?
Do not build in android studio but instead use the command line.
Risk:
What is the risk level of this cherry-pick?
Build change but it is a revert and a removal of a branch of code behind a check for launching from android studio.
Test Coverage:
Are you confident that your fix is well-tested by automated tests?
No tests for this feature as it would have required launching android studio.
Validation Steps:
What are the steps to validate that this fix works?
Use compileOnly dependencies in an app that also uses dynamic download.