Status Update
No update yet.
Comments
pe...@gmail.com
Maybe a dup of
sg...@google.com
cl...@google.com
Android Gradle Plugin: 8.7.1
Could you try the latest canary, AGP 8.8.0-alpha09?
cl...@google.com
I just updated to Android Gradle Plugin: 8.7.2 and the bug is fixed.
pu...@gmail.com
I spoke too soon. The bug appears gone when I use a different computer, but that is only because the lint check is disabled on it. The computer with the false positive is a new cloning of my github project which apparently has the lint check enabled. The AGP 8.8.0-alpha09 plugin will not work on ladybug, and I'm too busy to switch to a canary build of android studio just to fix a false positive lint check, sorry.
sg...@google.com
I just tried running lint on two more of my computers, one which also has a fresh clone of the github project, and one which has an "ancient" (but up to date) clone of the project -- the two computers have very different Settings -> Editor -> Inspections choices. The old clones do not have this lint check anywhere in their choices, whereas new clones do. Very odd indeed. (I have .idea/ in my .gitignore BTW).
pu...@gmail.com
I understand that it's not trivial to change AGP version; sorry for suggesting that first.
Actually, there is a better way to test: android.experimental.lint.version=8.8.0-alpha09 which will just change the Lint version.
pu...@gmail.com
I decided it was easier to download Android Studio Ladybug Feature Drop | 2024.2.2 Canary 9 than to figure out how to use a different version of lint (a search of stackoverflow suggests this is impossible for what that is worth). Using AGP 8.8.0-alpha09 and gradle-8.10.2-bin.zip on Canary the same error occurs. It looks like it is caused by the K2 compiler mode, because the Inspections options for this lint check does not appear until you enble K2 mode (nor does the false positive error).
to...@yahoo.com
Thank you for trying the latest canary version of Studio and AGP, I really appreciate that.
I rather confirmed that, with that canary (AGP 8.8.0-alpha09),
I also tried altering problematic produceState call with conditional assignment to value, which also works fine. I tried a similar code pattern on compose runtime ProduceStateDetector and its tests, but no luck.
Then... my next guess is whether it is from an old compose runtime, assuming this might be a dup of
bi...@google.com
The compose runtime is from the androidx-compose-bom = "2024.10.01", which is 1.7.5, which is the latest stable version according to its webpage. The project uses libs.versions.toml and gradle assures me that all the versions are up to date (for what that is worth - sometimes I have to manually update versions). I enclose the libs.versions.toml the project uses. The project is my copy of the "Crane" sample app which I have verbosely commented and try to keep up to date with the latest libraries and APIs. The source code involved is in my github repo in the Crane project:
The file the false positive is in is:
Crane/app/src/main/java/androidx/compose/samples/crane/details/DetailsActivity.kt
hu...@google.com
Thank you again for sharing all the details!
With the repo, I can reproduce the issue:
$ ./gradlew lint
> Task :app:lintDebug FAILED
Lint found 1 errors, 8 warnings. First failure:
.../Composables/Crane/app/src/main/java/androidx/compose/samples/crane/details/DetailsActivity.kt:243: Error: produceState calls should assign value inside the producer lambda [ProduceStateDoesNotAssignValue from androidx.compose.runtime]
val uiState: DetailsScreenUiState by produceState(
~~~~~~~~~~~~
Explanation for issues of type "ProduceStateDoesNotAssignValue":
produceState returns an observable State using values assigned inside the
producer lambda. If the lambda never assigns (i.e value = foo), then the
State will never change. Make sure to assign a value when the source you
are producing values from changes / emits a new value. For sample usage see
the produceState documentation.
Vendor: Jetpack Compose
Identifier: androidx.compose.runtime
Feedback: https://issuetracker.google.com/issues/new?component=612128
...
FAILURE: Build failed with an exception.
...
which is a build error in CLI. That is indeed a dup of
$ git diff
diff --git a/Crane/gradle/libs.versions.toml b/Crane/gradle/libs.versions.toml
index c3b2e3ca..c488d929 100644
--- a/Crane/gradle/libs.versions.toml
+++ b/Crane/gradle/libs.versions.toml
@@ -4,7 +4,7 @@
#####
[versions]
accompanist = "0.34.0"
-androidGradlePlugin = "8.7.2"
+androidGradlePlugin = "8.8.0-alpha09"
androidx-activity-compose = "1.9.3"
androidx-appcompat = "1.7.0"
androidx-benchmark = "1.3.3"
diff --git a/Crane/gradle/wrapper/gradle-wrapper.properties b/Crane/gradle/wrapper/gradle-wrapper.properties
index 1918a64e..9c74e424 100644
--- a/Crane/gradle/wrapper/gradle-wrapper.properties
+++ b/Crane/gradle/wrapper/gradle-wrapper.properties
@@ -14,6 +14,6 @@
#Sat Nov 2 07:49:36 AM EDT 2024
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-8.9-bin.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-8.10.2-all.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
$ ./gradlew lint
...
BUILD SUCCESSFUL in 1m 51s
31 actionable tasks: 30 executed, 1 from cache
build went well.
However, K2 UAST's IDE path still has an issue on binary resolution for @Composable. :( That part is a dup of
hu...@google.com
Aha! I see the problem. I always use the "Problems" tool window of the IDE to run lint. When I use "./gradlew lint" I get the same results as you do. Apparently the IDE is running lint wrong, feeding lint mangled code, misinterpreting lint's results, or using cached values from AGP 8.7.2 instead of using 8.8.0-alpha09 values. (But these are just guesses of course.)
hu...@google.com
Apparently the IDE is running lint wrong, feeding lint mangled code, misinterpreting lint's results, or using cached values
The issue is the Kotlin compiler front end; when lint within AGP, we have to bundle and invoke our own copy of the Kotlin compiler front end. But when we run inside the IDE, we directly reuse the one from the Kotlin plugin; that way we don't have to re-analyze your code etc, so it's more performant. But that means that lint running in the IDE and lint running from AGP use potentially different versions of the front end.
to...@yahoo.com
hobby. Let me know if I can be of any help.
On Tue, Nov 5, 2024 at 10:51 AM <buganizer-system@google.com> wrote:
hu...@google.com
Since CLI-side fix is already there, it's relatively easy(?) to port that to IDE-side, and actually ready; see attached screenshot.
pu...@gmail.com
I also have a project producing this error, but noticed it only happens in debug. In release, it builds fine. I can attach a r8dump.zip for it if necessary. Although in the zip produced, library.jar and program.jar are corrupted.
hu...@google.com
Please run the build with -Dcom.android.tools.r8.dumpinputtodirectory=. instead of -Dcom.android.tools.r8.dumpinputtofile, hopefully it will not be corrupted.
Make sure the build fails with The given file ... is located outside the root directory, and send us the dumpNNNN.zip files. Thanks a lot!
to...@yahoo.com Restricted
to...@yahoo.com
I can confirm #18 (thanks!, didn't think of trying that)
The failure only happens in debug builds (as uploaded in previous) while it builds fine and deploys without an issue in release builds.
hu...@google.com
That's great, thanks! (Release builds use a different pipeline, so it doesn't hit this code path.)
@Clément: Could you take a look at the dump above and see why in the desugaring graph (see com.android.tools.r8.D8Command.Builder#setDesugarGraphConsumer) D8 reports an edge to/from android.jar and whether that is expected?
If the behavior is correct in D8, I will fix this issue in AGP.
hu...@google.com
Update: By patching AGP with the input dump above, I can see that D8 reports the following dependency to AGP (via com.android.tools.r8.DesugarGraphConsumer#accept):
dependent = {ArchiveEntryOrigin@25758} "dump12086563528200/program.jar:com/.../.../channels/io/MyPipedInputStream.class"
dependency = {ArchiveEntryOrigin@25759} "Sdk/platforms/android-35/android.jar:java/io/InputStream.class"
Do we know why D8 reports that dependency given minSdk >= 24 (26 in the input dump)?
(It would be great to track this down before beta branching that's happening today.)
hu...@google.com
Steps to reproduce
Based on the input dump above, I've managed to reproduce this issue in a project (see attached):
- Create a project with
appandlib(Android library), using AGP 8.5.2 to 8.7.1, minSdk = 24+ - In
app, setisCoreLibraryDesugaringEnabled = trueandcoreLibraryDesugaring("com.android.tools:desugar_jdk_libs_nio:2.1.0") - In
lib, create a class that implementsjava.io.InputStreamorjava.io.PipedInputStream:
class ExampleClass(pipeSize: Int) : java.io.PipedInputStream(pipeSize)
- Run
./gradlew :app:mergeLibDexDebug, the build will fail with:
> Transform bundleLibRuntimeToDirDebug (project :lib) with DexingNoClasspathTransform
ERROR: D8: java.lang.IllegalStateException: The given file 'Sdk/platforms/android-34/android.jar' is located outside the root directory 'MyApplication/lib/build/intermediates/runtime_library_classes_dir/debug/bundleLibRuntimeToDirDebug'
Root cause
The issue is a combination of 2 factors:
- AGP doesn't expect desugaring dependencies between project's classes and
android.jar - D8 in some cases reports dependencies between the
ExampleClassabove andjava.io.InputStream(RetargetInterface)inandroid.jar
Workarounds
- Use
coreLibraryDesugaring("com.android.tools:desugar_jdk_libs_nio:2.0.4")instead of2.1.0+
Fix
- AGP: Ignore dependencies between project's classes and
android.jar - D8: Investigate root cause #2 and see why the behavior is inconsistent between
desugar_jdk_libs_nio:2.0.4and2.1.0+
hu...@google.com
- AGP: Ignore dependencies between project's classes and android.jar
We've done this in
Thanks a lot for this report and for helping us debug this issue!
Follow up
I'm closing this issue now, but it would be great if R8 team could verify the following, as it may indicate some bug in D8.
- D8: Investigate root cause #2 and see why the behavior is inconsistent between desugar_jdk_libs_nio:2.0.4 and 2.1.0+
ch...@google.com
Bugjuggler: wait until 20241120 -> clementbera
an...@google.com
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 Feature Drop | 2024.2.2 Canary 9
- Android Gradle Plugin 8.8.0-alpha09
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!
ch...@google.com
I opened
pu...@gmail.com
Confirming it is fixed in Canary 9.
However, Canary 9 introduced a new unrelated issue for me:
to...@yahoo.com
I don't get the error described, but any source code changes are not reflected when I hit "Debug". I have to manually build first.
I added myself to the newest issue...
cl...@google.com
Could you confirm whether it is possible to have a (desugaring) dependency between the project's classes and android.jar when minSdk >= 24?
That is possible when using desugared library. Most desugaring happen below 24, but some methods are desugared up to latest android.
I see java.io.InputStream#transferTo(java.io.OutputStream) is desugared with desugared library up to android 32 so that makes sense.
to...@yahoo.com
meerkat / agp 8.9.x and suga 2.1.3 .... seems to build again ok.
thanks!
Description
Build failure after upgrading the desugar library to 2.1.0 It works in AGP 8.4.x.