Fixed
Status Update
Comments
je...@google.com <je...@google.com> #2
This was broken by 3bca759a5ff08352de831bb1e9b61b1ec2b3362d.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
hu...@google.com <hu...@google.com> #3
Almost 2 months later and this is still broken
hu...@google.com <hu...@google.com> #4
Since there is no progression, I wanted to share our quick-fix for the issue.
#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages
#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages
an...@google.com <an...@google.com> #5
jb...@google.com What is the update on this?
Description
Steps to reproduce
./gradlew help
, it will fail with:./gradlew help
again without updating Gradle, it will fail with:Root cause
At this changehttps://android.googlesource.com/platform/tools/base/+/27e840abc64595652fd05ac564660b983ef8a478 (merged Jun 7, 2022), we use a static variable to record whether the Gradle version check has been performed. This is to avoid running the check multiple times, once for each subproject.
However, a static variable is not suited for this use case for 2 reasons:
Potential fix
We can replace the static variable with a property in a cross-classloader BuildService. This will fix both the scope and lifetime issues above (the scope will be JVM-scoped, cross-classloader, and the lifetime will be per build).
We've been talking about this cross-classloader BuildService for a while, maybe this is a good opportunity to implement it.