IssueTracker

Hey, sorry for coming back to this so late. We've never seen this. Without any repro steps it's going to be hard to do anything about it.

We've some cases where the Gradle daemon gets started but Studio cannot connect to it and the Studio side Gradle code handling connection to the daemon will keep spawning new ones if the connection does not get established. In this instance though the fact that the build window shows all these daemon running means that this is a different problem.

Hello, I had the issue reproduce on first project open after upgrading Android Studio from JetBrains Toolbox. Note that the project has a buildSrc.

I think you can reproduce it with the same steps if nothing changed since Arctic Fox alpha 08.

When you upgraded from the toolbox, can you indicate which version you started from and what you upgraded to?

Yes, actually it's in the title of the issue: Canary 7 to 8 of Arctic Fox.

oops, thanks :)

I just had that again when upgrading from AS BB Canary 2 to AS BB Canary 6. I am attaching screenshots and a screencast so you can see how it is materializing.

Note that for some reason, Gradle sync is complaining about JDK location while it was working perfectly on Canary 2 (and I only touched the AGP version), I don't know why and I don't plan to investigate that now, I'll just try to fix it and move it.

Wait, I cannot view my own restricted content? 😒

I don't know the difference between restricted and restricted+ beyond difference in access level. I think googlers have access to restricted for sure (I can see your last 2 restricted comments/attachement) but I'm not sure about restricted+.

I got the issue again upgrading from BumbleBee Canary 6 to Canary 7 (note that I upgraded AGP externally while AS wasn't open, because I wanted to save time by skipping a predictably failing Gradle sync).

This time, I got an interesting error in one of the 10 concurrent Gradle sync attempts:

Timeout waiting to lock buildSrc build lock. It is currently in use by another Gradle instance.
Owner PID: 9842
Our PID: 9845
Owner Operation: 
Our operation: 
Lock file: /Users/me/AndroidStudioProjects/ProjectName/buildSrc/.gradle/noVersion/buildSrc.lock

It looks like there are now file locks in place, allowing the issue to be detected in a better way, but it is still happening.

I am wondering if there is any cache that would depend on the AGP version of the last Gradle sync, and that when there's a difference between last sync AGP and the AGP AS is looking for, or the AGP of the project, AS tries doing Gradle syncs differently from how it'd try to do it when you click the Gradle sync button in the toolbar, the banner, or the Gradle tool window.

Do you know how close I am to the culprit?

Would you be able to share .idea/gradle.xml file with us? Or can you just confirm that there is only one <GradleProjectSettings> entry in the file?

I just attached it (restricted), and I can confirm there's only one <GradleProjectSettings> xml tag.

Thank you!

I found the problem in the code. We incorrectly handle detection and presence of data from previous versions of Android Studio in the cache.

Until we fix it, you should be able to get out of this state by invalidating the cache or specifically deleting the external_build_system in the Android Studio's system directory.

Hello, has it been fixed in BumbleBee Canary 10?

I had the issue when upgrading to Canary 9, but not when upgrading to Canary 10.

No, it hasn't been included in any canaries yet. However, once you have resolved the issue it should not re-apear.

The problem was triggered when Android Studio attempted to re-sync a project because of outdated cached data and upgrading to a newer canary version does not usually require re-syncing.

I'm assuming you meant "hasn't".

Reading again what you wrote, I guess it was caused by the fact that I did an Invalidate caches and restart (for another reason), something I rarely do, so yes, not fixed, but not prone to happen again this soon in my specific case.

yes, sure (edited the comment), thank you!

"Invalidate caches" should resolve it and I don't expect "9 to 10" upgrade run into this issue.

Is that a spam comment just above?

Yuriy, I am assuming this code has now been merged and released ?

yes

Thank you for addressing this 🙏

Have a great day!