Status Update
Comments
sp...@google.com <sp...@google.com> #2
I've submitted a fix for this, which should (I hope) make it into Jellyfish Canary 12. There's a relatively straightforward workaround, which is to explicitly declare the version of the com.android.tools.build:gradle
artifact in all build files -- in the screenshot, your project has a versioned classpath
dependency, but also an unversioned one, and it's that unversioned one that tripped up the AGP Upgrade Assistant. Since there is that workaround of making sure that all the classpath dependencies on com.android.tools.build:gradle
have an explicit version, we probably won't patch this for Iguana, I'm afraid.
Thanks very much for the report!
ga...@google.com <ga...@google.com>
sp...@google.com <sp...@google.com>
sp...@google.com <sp...@google.com> #3
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Jellyfish | 2023.3.1 Canary 12
- Android Gradle Plugin 8.4.0-alpha12
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
sp...@google.com <sp...@google.com> #5
mi...@allegro.com <mi...@allegro.com> #6
same problem in latest koala, AGP upgrade assistant never opens
Please could you open a new issue, and upload enough details about your project to be able to investigate or (ideally) reproduce the problem? Thank you!
sp...@google.com <sp...@google.com> #7
Is the missing file always kotlin-stdlib-1.9.22.jar ?
Do you have any other information you can share to help me reproduce the issue?
mi...@allegro.com <mi...@allegro.com> #8
No, it's not always kotlin-stdlib. I've attached the full report with redacted file paths and module names. Please note it reports some resources as unused at the end which is not true and probably caused by the premature failure.
Additional info:
- Lint configuration
lint {
abortOnError = true
warningsAsErrors = true
checkDependencies = true
ignoreTestSources = true
baseline = File("lint-baseline.xml")
}
We also use some custom Lint rules which are applied via dependencies block lintChecks project(':lint-checks')
We have a large baseline file with the following format:
<issues format="6" by="lint 8.2.2" type="baseline" client="gradle" dependencies="true" name="AGP (8.2.2)" variant="all" version="8.2.2">
- Cache - our .gradle/caches are shared between builds via Github Action
gradle/actions/setup-gradle@v3
- name: Setup Gradle Cache
uses: gradle/actions/setup-gradle@v3
with:
gradle-home-cache-cleanup: true
gradle-home-cache-excludes: caches/build-cache-1
We exclude build-cache as it is provided by our remote cache server. Removing .gradle/caches
does not influence this issue - lint still fails with attached logs.
- Github Actions - we use Ubuntu 22.04 runners
ma...@allegro.com <ma...@allegro.com> #9
After a quick investigation, we suspect that the root cause of those fails is the build/intermediates/lint_model/debug/debug_artifact_libraries.xml
file. When looking at it's content in an example module:
<libraries>
<library
name="androidx.annotation:annotation-jvm:1.6.0@jar"
jars="/Users/name.surname/.gradle/caches/modules-2/files-2.1/androidx.annotation/annotation-jvm/1.6.0/a7257339a052df0f91433cf9651231bbb802b502/annotation-jvm-1.6.0.jar"
resolved="androidx.annotation:annotation-jvm:1.6.0"
provided="true"/>
....
</libraries>
That's right, this file has a reference to a Gradle cache directory. I'm not a Gradle expert, but I assume that this is something that has potential to break the cache logic.
ma...@allegro.com <ma...@allegro.com> #10
This issue was discovered when using Gradle 8.5 and AGP 8.2.2, but I've tested it on Gradle 8.7 and AGP 8.3.2, still with the same results. Also, there are much more Lint outputs that use paths to Gradle cache, like build/intermediates/lint_model/debug/generateDebugLintModel/module.xml
. For now the only solution for us was to disable cache for Lint tasks, but obviously we would like to restore it as fast as possible. If you need any additional info to debug this issue, please let me know.
sp...@google.com <sp...@google.com> #11
Thanks for the info.
I think the main underlying problem here is that the lint analysis task caches its output even when there is a LintError
, and I think the right fix is for AGP to throw an exception from the lint analysis task when there is a LintError
... This was discussed previously in the context of OOM
s; previously we decided not to throw an exception in cases other than OOM
s, but we didn't consider the case of rare exceptions getting cached as LintError
s in the build cache.
I think in your case, there is occasionally a NoSuchFileException
during lint analysis, and then the corresponding LintError
keeps showing up in subsequent builds because it gets cached in the build cache.
As far as what's causing the LintError
, I wonder if it's because of "gradle-home-cache-cleanup: true
" from #8... I'm not sure how that's implemented, but if it just cleans the Gradle home caches after each build, then it could cause that NoSuchFileException
if there is another build running simultaneously on the same machine.
Re: #9, I don't think the Gradle cache directory path is causing the issue because that file is not consumed by the lint analysis task.
mi...@allegro.com <mi...@allegro.com> #12
Regarding gradle-home-cache-cleanup: true
I can say with confidence that it has nothing to do with the issue, as it was occurring for a long time before we started using this feature. The feature itself cleans Gradle home artifacts that were not used during build before saving the cache to Github Actions cache.
sp...@google.com <sp...@google.com> #13
I think the right fix is for AGP to throw an exception from the lint analysis task when there is a LintError
This has been implemented and will be included in AGP 8.7.0-alpha08.
an...@google.com <an...@google.com> #14
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Ladybug | 2024.2.1 Canary 8
- Android Gradle Plugin 8.7.0-alpha08
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
an...@google.com <an...@google.com> #15
Further fixes for this issue are now available in:
- Android Studio Ladybug | 2024.2.1 Canary 9
- Android Gradle Plugin 8.7.0-alpha09
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
kz...@gmail.com <kz...@gmail.com> #16 Restricted+
pa...@gmail.com <pa...@gmail.com> #17
For the record, I think this has now removed the ability:
- to observe LintError in the report XML/HTML/TXT/SARIF (i.e. no tooling can detect it), report task doesn't run because dependency fails.
- Knock-on: if there's a LintError, it has to be fixed BEFORE we can see and fix any other problems, even if there's just one rogue rule.
- Knock-on: can't see the formatted clear stack trace,
LINT_PRINT_STACKTRACE=true
has no effect any more - Knock-on: users have to read the logs of CI to understand the failure, even when there are artifacts/PR annotations are used.
- to suppress LintError in lint.xml (e.g. a check that only fails in one specific case, and otherwise useful)
- to baseline LintErrors (e.g. a check that only fails in one specific case, and otherwise useful)
Reported
Description
I only saw this once locally, so low priority at the moment
(scan has details on java, AGP, gradle versions)https://ge.androidx.dev/s/x2ecfl4oiiqig