IssueTracker

Alon, can you take a look?

I was finally able to repro, and what happens is that if you finish the Gemini onboarding flow, you'll get the Ask Gemini text, but you have to restart the IDE to get the link to show up.

We need to fix that, or tweak the text before rebooting to either hide it or say something like ("reboot to enable Ask Gemini feature").

Background:

This feature is implemented by chaining together 2 separate pieces:

1. com/android/tools/idea/logcat/messages/MessageFormatter.kt adds the text "Ask Gemini". For every message from logcat, we check if it is an exception, and if so, add the text "Ask Gemini".

2. A separate EditorHyperlinkDetector is responsible for "linkifying" the text. But this detector, only adds the studio bot specific logic if studio bot was enabled during initialization.

Due to the inconsistency in how (1) and (2) detect whether studio bot is available, we run into this situation when:

1. On IDE start up, logcat is initializated. Studio Bot is not enabled at this time, so the hyper link detector doesn't add the studio bot specific logic.
2. User on boards to Studio bot. After this, the MessageFormatter will start adding the text "Ask Gemini" for exceptions.

I think we should do a simple fix right away: We should always add the StudioBotFilter to the hyper link detector. This can then check for whether studio bot is enabled internally, which should make (1) and (2) consistent in how they check for studio bot being active.

Can you also add an option to disable the feature, even if I logged in to Gemini?

We often share logcat output in bugreports and such. This is noise we can do without.

We often share logcat output in bugreports and such. This is noise we can do without.

Just want to confirm: you are copying logcat output from the logcat pane in Studio in your bugreports? (These aren't added to the real adb logcat output, they are only shown inside Studio, so they won't be in any automated bug report systems)

Sounds good. Adding a setting is tracked in b/363791805. This bug will focus on fixing the original issue.

http://ag/29090651 fixes the issue. Should be available in the next canary release.

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 1
• Android Gradle Plugin 8.8.0-alpha01

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!

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 b/368420773, and if I updated AGP/gradle:

$ 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 b/360354551. Alas, even after 2024.3 merge, it's still reproducible as attached screenshot.

Filed https://youtrack.jetbrains.com/issue/KTIJ-31887

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.)

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.

Since CLI-side fix is already there, it's relatively easy(?) to port that to IDE-side, and actually ready; see attached screenshot.