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 "@test-exemption-reviewer" in 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.

Some notes/questions:

• Are the lockfiles actually generated? If so, where? I ran ./gradlew :generateLockfiles --write-locks, but no .lockfile files were generated, neither in my app nor in Android plugins under ~/.pub-cache.
• Why does "Sync project with Gradle files" in IntelliJ trigger lockfile generation on every sync, but when I build my app normally (./gradlew :app:assembleDebug), then lockfile generation isn't triggered?
• How can I run the equivalent of "Sync project with Gradle files" from the terminal? I can image it might be useful for testing this.

cc gradle gurus @GaryQian @gmackall @reidbaker

Some notes/questions:

• Are the lockfiles actually generated? If so, where? I ran ./gradlew :generateLockfiles --write-locks, but no .lockfile files were generated, neither in my app nor in Android plugins under ~/.pub-cache.
• Why does "Sync project with Gradle files" in IntelliJ trigger lockfile generation on every sync, but when I build my app normally (./gradlew :app:assembleDebug), then lockfile generation isn't triggered?
• How can I run the equivalent of "Sync project with Gradle files" from the terminal? I can image it might be useful for testing this.

cc gradle gurus @GaryQian @gmackall @reidbaker

I don't know the answer to most of these off the top of my head. IIRC flutter 2.* used a beta gradle feature to generateLockfiles which has since been made stable but the activation might have a different name than the preview feature.

@jwren could you point me towards the code that run in Intellij when we sync gradle files? If so then I can dig into the differences between the IDE behavior and the command line behavior and give a command line equivalent.

Is this ready for review? Happy to take a look if so, but just want to be sure because the PR is still in draft

Added you for the discussion on #147837 (comment)

@reidbaker we have a dart cli which calls gradle on our behalf, cli tool is here: https://github.com/flutter/flutter-intellij/tree/master/tool/plugin

Thank you @jwren! @bartekpacia let me dig in this week and give you better answers.

Thanks a ton, this looks like a good starting point.

@reidbaker thanks! If you're busy though, don't bother really, I'll do it myself and if I fail, then I'll ping you back:)

We've found that this actually gets into an infinite loop if we have a plugin added in an init script in the gradle home directory, the Flutter plugin gets applied to the :dependencies call made by :generateLockfiles task init code, which in turns calls :dependencies again.

I can confirm that your fix fixes the infinite loop problem too.

Additional interesting find is that the task :dependencies is not run normally, only when additional plugins are loaded by our init script in the home directory, so

Are the lockfiles actually generated?

I'd say no?

Why does "Sync project with Gradle files" in IntelliJ trigger lockfile generation on every sync, but when I build my app normally (./gradlew :app:assembleDebug), then lockfile generation isn't triggered?

Yes, exactly what we're seeing

After further digging, I've found that our plugin evaluates the project's tasks, which triggers the :generateLockfiles initialization code that runs Gradle, and that starts an infinite loop because our plugin is applied again. That concerns this PR because evaluating a project's task is what triggers the :generateLockfiles init code that triggers gradle :dependencies, adding to the build time.

How can I run the equivalent of "Sync project with Gradle files" from the terminal? I can image it might be useful for testing this.

Just run gradlew tasks in a flutter test app project's android/ folder. It will evaluate all tasks, and also runs :dependencies because of the task init code.

I just talked with @runningcode, a Gradle engineer, on droidcon Berlin and asked him how we can trigger Gradle Sync without an IDE (so we can actually test that our fix will work). He suggested using https://github.com/gradle/gradle-profiler. It has a lot of various config options, some of the ones we might wanna take a look at are apply-build-script-change-to and clear-android-studio-cache-before.

Thanks a lot @runningcode! :)

(PR Triage): Hey @bartekpacia do you have plans to continue with this PR? Thanks!

Hey @Piinks! Yes I do!

Some notes

To trigger a Gradle sync (the same way we can do from IntelliJ), we will likely have to create a scenario file.

gradle-profiler --benchmark --scenario-file performance.scenarios intellijSync

# performance.scenarios

intellijSync {
    # Measure an Android studio sync
    title = "Android Studio Sync"
    # Note: you need to have local.properties file in your project with sdk.dir set
    android-studio-sync {
        # Override default Android Studio jvm args
        # studio-jvm-args = ["-Xms256m", "-Xmx4096m"]
        # Pass an IDEA properties to Android Studio. This can be used to set a registry values as well
        # idea-properties = ["gradle.tooling.models.parallel.fetch=true"]
    }
}

See also

• Search for android-studio-sync in Gradle profiler sources

How can I run the equivalent of "Sync project with Gradle files" from the terminal? I can image it might be useful for testing this.

Just run gradlew tasks in a flutter test app project's android/ folder. It will evaluate all tasks, and also runs :dependencies because of the task init code.

Thanks @zsolt-marta-bitrise, this is true!

I'm wondering why it's happening – why is generateLockfiles a dependency of dependencies lifecycle task?

oh my, it's the missing doLast 🤦🏻

superseded by #162220