Fixed
Status Update
Comments
xa...@google.com <xa...@google.com> #3
(reposting under work account)
We have been hitting this issue constantly. Is it possible to configure those tasks to be non cacheable as a workaround or is that only possible inside of AGP?
ga...@google.com <ga...@google.com> #4
Currently the only way to disable caching for dexing transforms is to patch AGP manually by providing a patched DexTransform.kt
file in buildSrc
. Please see
ga...@google.com <ga...@google.com> #5
Thanks. Ignoring potential build perf impacts, if we essentially commented out the processIncrementally
block in DexingTransform.kt
and always ran non-incrementally, would that workaround this issue?
an...@google.com <an...@google.com> #6
Yes, always run the dex transform non-incrementally is another workaround.
fi...@gmail.com <fi...@gmail.com> #7 Restricted+
Restricted+
Comment has been deleted.
wi...@gmail.com <wi...@gmail.com> #8 Restricted
Restricted
Comment has been deleted.
Description
The
JavaPreCompileTask
computes KSP and annotation processors that are consumed in downstreamJavaCompile
tasks. For annotation processors, the compilation task in AGP computes if any processors are non-incremental, and (correctly) reports a warning for any non-incremental processors found.However, there's a bug in
JavaPreCompileTask
's logic as it merges the KSP and annotation processing classpath when computing, meaning that dependencies on the KSP classpath are incorrectly treated as if they are going to be on the JavaCompileannotationProcessorClasspath
.Essentially, in this bit of logic
It shouldn't be merging together the ksp and annotation processor artifacts, as KSP dependencies do not participate in the
JavaCompile
classpath.In the meantime, I can work around this with the following snippet in Kotlin gradle DSL.