Status Update
Comments
xa...@google.com <xa...@google.com> #2
Lint options:
lintOptions {
lintConfig = file('lint.xml')
abortOnError true
xmlReport true
htmlReport true
checkDependencies true
}
Also, our project has custom lint rules. Failure happens with a dependency of 26.6.3 and 27.0.0.
Is any way to downgrade lint runner? This problem is keeping us from using AGP 4.0
au...@google.com <au...@google.com> #3
Attached slightly different stacktrace for the same problem.
Wonder if disabling some lint rules could help to "fix" this problem, as it is also blocking for us 4.0 AGP upgrade.
sp...@google.com <sp...@google.com> #4
Notes:
I suspect the exceptions are happening now because JetBrains recently changed an assert
statement into a hard failure (see
I.e., it's possible that Lint has been hitting this code path all along, and only now it is causing a problem.
This has been difficult to investigate so far because the failure is nondeterministic and also deep inside the Kotlin compiler. Plus, JetBrains seems to be hitting this code path occasionally too (hence why they changed the assert into a hard failure), so I'm not even sure whether Lint is implicated or not.
sp...@google.com <sp...@google.com> #5
It could also explain why not all lint rules were working from time to time (
Is any public issue created I could follow?
sp...@google.com <sp...@google.com> #6
Has anyone tried this with 4.1.0-beta2? We're using a more recent version of UAST and the Kotlin compiler there. It's not clear that it's fixed but -- there's a chance :-)
Description
AndroidLintTask
lists the lint baseline file (e.g.lint-baseline.xml
) as an@InputFiles
property, but the file is also functioning as an@Output
of the task, since Lint, as documentedThis isn't good practice in Gradle, and leads to some odd behavior.
For instance, if you:
gradlew app:lint -Dlint.baselines.continue=true
, generating a new baseline filegradlew app:lint -Dlint.baselines.continue=true
The baseline file is not re-created, since Gradle observes the same "before" state for both invocations and marks the task as
Up-To-Date
(Gradle doesn't include the file in the "after" snapshot for the task because the file isn't marked as an@Output
). A fix/workaround is pending for this particular issue, but there may be other issues inherent to this non-idiomatic use of the Gradle API.This comment proposes a fix in AGP for the broader issue.