IssueTracker

I've just updated the documentation snapshot -- https://googlesamples.github.io/android-custom-lint-rules/usage/changes.md.html should now correctly reflect the latest changelist.

(And I'm thinking about adding some code to automatically infer the applicable version information into the issue documentation the way it's listed in the version table for third party libraries.)

The docs now contain exact release information for issues as well, e.g. on https://googlesamples.github.io/android-custom-lint-rules/checks/AppLinkSplitToWebAndCustom.md.html it says "Since: 8.8.0-alpha08 (October 2024)".

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 Meerkat | 2024.3.1 Canary 8
• Android Gradle Plugin 8.9.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!

Still hanging everywhere in AS2024.3.1.6

You MUST prioritize this issue, i don't like reverting back because here are so much other good stuff which is fixed...

May be not related, but I took look at the last log:

2024-12-17 10:56:19,614 [1220737]   INFO - #com.android.tools.idea.gradle.run.MakeBeforeRunTask - Gradle invocation complete, build result = com.android.tools.idea.gradle.project.build.invoker.AssembleInvocationResult@99befcf
2024-12-17 10:56:19,615 [1220738] SEVERE - #c.i.u.SlowOperations - Slow operations are prohibited on EDT. See SlowOperations.assertSlowOperationsAreAllowed javadoc.
java.lang.Throwable: Slow operations are prohibited on EDT. See SlowOperations.assertSlowOperationsAreAllowed javadoc.
	at com.intellij.openapi.diagnostic.Logger.error(Logger.java:376)
	at com.intellij.util.SlowOperations.assertSlowOperationsAreAllowed(SlowOperations.java:114)
	at com.intellij.workspaceModel.core.fileIndex.impl.WorkspaceFileIndexDataImpl.ensureIsUpToDate(WorkspaceFileIndexDataImpl.kt:153)
	at com.intellij.workspaceModel.core.fileIndex.impl.WorkspaceFileIndexDataImpl.getFileInfo(WorkspaceFileIndexDataImpl.kt:98)
	at com.intellij.workspaceModel.core.fileIndex.impl.WorkspaceFileIndexImpl.getFileInfo(WorkspaceFileIndexImpl.kt:267)
	at com.intellij.workspaceModel.core.fileIndex.impl.WorkspaceFileIndexImpl.findFileSet(WorkspaceFileIndexImpl.kt:220)
	at com.intellij.openapi.roots.impl.ProjectFileIndexImpl.isInProject(ProjectFileIndexImpl.java:84)
	at com.intellij.psi.search.ProjectAndLibrariesScope.contains(ProjectAndLibrariesScope.java:33)
	at com.intellij.psi.search.ProjectScopeBuilderImpl$3.contains(ProjectScopeBuilderImpl.java:92)
	at com.android.tools.idea.editors.build.PsiCodeFileChangeDetectorService.prepareMarkUpToDate$lambda$2(PsiCodeFileChangeDetectorService.kt:230)
	at com.android.tools.idea.editors.build.RenderingBuildStatusManagerImpl$buildListener$1.buildStarted$handleSuccess$lambda$0(RenderingBuildStatusManager.kt:210)
	at com.intellij.util.SlowOperations.allowSlowOperations(SlowOperations.java:205)
	at com.android.tools.idea.editors.build.RenderingBuildStatusManagerImpl$buildListener$1.buildStarted$handleSuccess(RenderingBuildStatusManager.kt:209)
	at com.android.tools.idea.editors.build.RenderingBuildStatusManagerImpl$buildListener$1.buildStarted$handleBuildResult(RenderingBuildStatusManager.kt:219)
	at com.android.tools.idea.editors.build.RenderingBuildStatusManagerImpl$buildListener$1.access$buildStarted$handleBuildResult(RenderingBuildStatusManager.kt:185)
	at com.android.tools.idea.editors.build.RenderingBuildStatusManagerImpl$buildListener$1$buildStarted$1$1.invokeSuspend(RenderingBuildStatusManager.kt:229)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
	at com.intellij.openapi.application.TransactionGuardImpl.runWithWritingAllowed(TransactionGuardImpl.java:236)
	at com.intellij.openapi.application.TransactionGuardImpl.access$100(TransactionGuardImpl.java:25)
	at com.intellij.openapi.application.TransactionGuardImpl$1.run(TransactionGuardImpl.java:198)
	at com.intellij.openapi.application.impl.AnyThreadWriteThreadingSupport.runIntendedWriteActionOnCurrentThread$lambda$2(AnyThreadWriteThreadingSupport.kt:217)
	at com.intellij.openapi.application.impl.AnyThreadWriteThreadingSupport.runWriteIntentReadAction(AnyThreadWriteThreadingSupport.kt:128)
	at com.intellij.openapi.application.impl.AnyThreadWriteThreadingSupport.runIntendedWriteActionOnCurrentThread(AnyThreadWriteThreadingSupport.kt:216)
	at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:842)
	at com.intellij.openapi.application.impl.ApplicationImpl$3.run(ApplicationImpl.java:434)
	at com.intellij.openapi.application.impl.FlushQueue.runNextEvent(FlushQueue.java:117)
	at com.intellij.openapi.application.impl.FlushQueue.flushNow(FlushQueue.java:43)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
	at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
	at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
	at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.kt:675)
	at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.kt:573)
	at com.intellij.ide.IdeEventQueue.dispatchEvent$lambda$18$lambda$17$lambda$16$lambda$15(IdeEventQueue.kt:355)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computePrioritized(CoreProgressManager.java:857)
	at com.intellij.ide.IdeEventQueue.dispatchEvent$lambda$18$lambda$17$lambda$16(IdeEventQueue.kt:354)
	at com.intellij.ide.IdeEventQueueKt.performActivity$lambda$2$lambda$1(IdeEventQueue.kt:1045)
	at com.intellij.openapi.application.WriteIntentReadAction.lambda$run$0(WriteIntentReadAction.java:24)
	at com.intellij.openapi.application.impl.AnyThreadWriteThreadingSupport.runWriteIntentReadAction(AnyThreadWriteThreadingSupport.kt:128)
	at com.intellij.openapi.application.impl.ApplicationImpl.runWriteIntentReadAction(ApplicationImpl.java:916)
	at com.intellij.openapi.application.WriteIntentReadAction.compute(WriteIntentReadAction.java:55)
	at com.intellij.openapi.application.WriteIntentReadAction.run(WriteIntentReadAction.java:23)
	at com.intellij.ide.IdeEventQueueKt.performActivity$lambda$2(IdeEventQueue.kt:1045)
	at com.intellij.ide.IdeEventQueueKt.performActivity$lambda$3(IdeEventQueue.kt:1054)
	at com.intellij.openapi.application.TransactionGuardImpl.performActivity(TransactionGuardImpl.java:109)
	at com.intellij.ide.IdeEventQueueKt.performActivity(IdeEventQueue.kt:1054)
	at com.intellij.ide.IdeEventQueue.dispatchEvent$lambda$18(IdeEventQueue.kt:349)
	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.kt:395)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)
2024-12-17 10:56:19,616 [1220739] SEVERE - #c.i.u.SlowOperations - Android Studio Meerkat | 2024.3.1 Canary 6  Build #AI-243.22562.145.2431.12789491
2024-12-17 10:56:19,616 [1220739] SEVERE - #c.i.u.SlowOperations - JDK: 21.0.5; VM: OpenJDK 64-Bit Server VM; Vendor: JetBrains s.r.o.
2024-12-17 10:56:19,616 [1220739] SEVERE - #c.i.u.SlowOperations - OS: Windows 11
2024-12-17 10:56:19,616 [1220739] SEVERE - #c.i.u.SlowOperations - Last Action: Run

and some reference to that I am not running Linux subsystem (wsl.exe), is that a request in Meerkat ?

2024-12-17 11:04:24,832 [1705955]   WARN - #c.i.e.w.WslDistributionManager - Failed to run C:\WINDOWS\system32\wsl.exe --list --verbose: {exitCode=1, timeout=false, cancelled=false, stdout=, stderr=Windows-undersystem for Linux er ikke installert. Du kan installere ved å kjøre wsl.exe --install.
Hvis du vil ha mer informasjon, kan du gå til https://aka.ms/wslinstall
}, done in 52 ms
java.io.IOException: Failed to run C:\WINDOWS\system32\wsl.exe --list --verbose: {exitCode=1, timeout=false, cancelled=false, stdout=, stderr=Windows-undersystem for Linux er ikke installert. Du kan installere ved å kjøre wsl.exe --install.
Hvis du vil ha mer informasjon, kan du gå til https://aka.ms/wslinstall
}, done in 52 ms
	at com.intellij.execution.wsl.WslDistributionManagerImpl.loadInstalledDistributionsWithVersions(WslDistributionManagerImpl.java:85)
	at com.intellij.execution.wsl.WslDistributionManager.loadInstalledDistributions(WslDistributionManager.java:167)
	at com.intellij.execution.wsl.WslDistributionManager.getInstalledDistributions(WslDistributionManager.java:86)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(Unknown Source)
	at com.intellij.util.concurrency.ChildContext$runInChildContext$1.invoke(propagation.kt:101)
	at com.intellij.util.concurrency.ChildContext$runInChildContext$1.invoke(propagation.kt:101)
	at com.intellij.util.concurrency.ChildContext.runInChildContext(propagation.kt:107)
	at com.intellij.util.concurrency.ChildContext.runInChildContext(propagation.kt:101)
	at com.intellij.util.concurrency.ContextRunnable.run(ContextRunnable.java:27)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Unknown Source)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
2024-12-17 11:04:24,868 [1705991]   INFO - #c.i.e.w.WslDistributionManager - Cannot parse WSL distributions
java.io.IOException: Failed to run C:\WINDOWS\system32\wsl.exe --list --quiet: {exitCode=1, timeout=false, cancelled=false, stdout=, stderr=Windows-undersystem for Linux er ikke installert. Du kan installere ved å kjøre wsl.exe --install.
Hvis du vil ha mer informasjon, kan du gå til https://aka.ms/wslinstall
}
	at com.intellij.execution.wsl.WslDistributionManagerImpl.doFetchDistributionsFromWslCli(WslDistributionManagerImpl.java:156)
	at com.intellij.execution.wsl.WslDistributionManagerImpl.loadInstalledDistributionMsIds(WslDistributionManagerImpl.java:41)
	at com.intellij.execution.wsl.WslDistributionManager.loadInstalledDistributions(WslDistributionManager.java:182)
	at com.intellij.execution.wsl.WslDistributionManager.getInstalledDistributions(WslDistributionManager.java:86)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(Unknown Source)
	at com.intellij.util.concurrency.ChildContext$runInChildContext$1.invoke(propagation.kt:101)
	at com.intellij.util.concurrency.ChildContext$runInChildContext$1.invoke(propagation.kt:101)
	at com.intellij.util.concurrency.ChildContext.runInChildContext(propagation.kt:107)
	at com.intellij.util.concurrency.ChildContext.runInChildContext(propagation.kt:101)
	at com.intellij.util.concurrency.ContextRunnable.run(ContextRunnable.java:27)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Unknown Source)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
2024-12-17 11:04:31,699 [1712822]   INFO - #c.i.o.p.DumbServiceImpl - enter dumb mode [Norva24 MSlam]
2024-12-17 11:04:31,743 [1712866]   INFO - #c.i.o.p.MergingQueueGuiExecutor - Running task: (dumb mode task) com.intellij.openapi.roots.impl.PushedFilePropertiesUpdaterImpl$MyDumbModeTask@423a3c5 (reason: Push on VFS changes)
2024-12-17 11:04:31,752 [1712875]   INFO - #c.i.o.p.MergingQueueGuiExecutor - Task finished: (dumb mode task) com.intellij.openapi.roots.impl.PushedFilePropertiesUpdaterImpl$MyDumbModeTask@423a3c5 (reason: Push on VFS changes)
2024-12-17 11:04:31,802 [1712925]   INFO - #c.i.o.p.DumbServiceImpl - exit dumb mode [Norva24 MSlam]
2024-12-17 11:04:31,908 [1713031]   INFO - #o.j.p.g.GradleManager - Instructing gradle to use java from C:/Program Files/Android Studio/Android Studio 2024.2.2.7/jbr
2024-12-17 11:04:32,039 [1713162]   INFO - #o.j.p.g.GradleManager - Instructing gradle to use java from C:/Program Files/Android Studio/Android Studio 2024.2.2.7/jbr
2024-12-17 11:04:55,832 [1736955]   INFO - #com.android.studio.ml.aida.AidaMetrics - Completion CES response: 
2024-12-17 11:07:25,597 [1886720]   WARN - #c.i.i.a.CopyTBXReferenceAction - Cannot find TBX tool for IDE: AndroidStudio

Paul pointed out that

It looks like it often involves the following, but not always:

   at com.android.tools.lint.client.api.AnnotationHandler.checkContextAnnotations(AnnotationHandler.kt:214)
   at com.android.tools.lint.client.api.AnnotationHandler.visitVariable(AnnotationHandler.kt:1082)

Indeed, at comment#3,

1. catch clause parameter

	at org.jetbrains.uast.kotlin.KotlinUSimpleReferenceExpression.resolve(KotlinUSimpleReferenceExpression.kt:44)
	at com.android.tools.lint.client.api.AnnotationHandler$checkContextAnnotations$1.visitSimpleNameReferenceExpression(AnnotationHandler.kt:219)
	at org.jetbrains.uast.kotlin.KotlinUSimpleReferenceExpression.accept(KotlinUSimpleReferenceExpression.kt:58)
	...
	at org.jetbrains.uast.UBlockExpression.accept(UBlockExpression.kt:21)
	at org.jetbrains.uast.UMethod.accept(UMethod.kt:45)
	at com.android.tools.lint.client.api.AnnotationHandler.checkContextAnnotations(AnnotationHandler.kt:214)
	at com.android.tools.lint.client.api.AnnotationHandler.visitVariable(AnnotationHandler.kt:1082)
	at com.android.tools.lint.client.api.UElementVisitor$DelegatingUastVisitor.visitVariable(UElementVisitor.kt:840)
	at org.jetbrains.uast.visitor.UastVisitor.visitParameter(UastVisitor.kt:16)
	at com.android.tools.lint.client.api.UElementVisitor$DispatchUastVisitor.visitParameter(UElementVisitor.kt:551)
	at com.android.tools.lint.client.api.UElementVisitor$DelegatingUastVisitor.visitParameter(UElementVisitor.kt:889)
	at org.jetbrains.uast.UParameter.accept(UVariable.kt:80)
	at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
	at org.jetbrains.uast.kotlin.KotlinUCatchClause.accept(KotlinUCatchClause.kt:55)
	at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
	at org.jetbrains.uast.UTryExpression.accept(UTryExpression.kt:79)

also some other logs:

2. lambda parameter

    at org.jetbrains.uast.UBlockExpression.accept(UBlockExpression.kt:21)
    at org.jetbrains.uast.UMethod.accept(UMethod.kt:45)
    at com.android.tools.lint.client.api.AnnotationHandler.checkContextAnnotations(AnnotationHandler.kt:214)
    at com.android.tools.lint.client.api.AnnotationHandler.visitVariable(AnnotationHandler.kt:1082)
    at com.android.tools.lint.client.api.UElementVisitor$DelegatingUastVisitor.visitVariable(UElementVisitor.kt:840)
    at org.jetbrains.uast.visitor.UastVisitor.visitParameter(UastVisitor.kt:16)
    at com.android.tools.lint.client.api.UElementVisitor$DispatchUastVisitor.visitParameter(UElementVisitor.kt:551)
    at com.android.tools.lint.client.api.UElementVisitor$DelegatingUastVisitor.visitParameter(UElementVisitor.kt:889)
    at org.jetbrains.uast.UParameter.accept(UVariable.kt:80)
    at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
    at org.jetbrains.uast.ULambdaExpression.accept(ULambdaExpression.kt:39)
    at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
    at org.jetbrains.uast.UCallExpression.accept(UCallExpression.kt:98)
    at org.jetbrains.uast.UQualifiedReferenceExpression.accept(UQualifiedReferenceExpression.kt:34)
    at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
    at org.jetbrains.uast.UBlockExpression.accept(UBlockExpression.kt:21)
    at org.jetbrains.uast.ULambdaExpression.accept(ULambdaExpression.kt:40)
    at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
    at org.jetbrains.uast.UCallExpression.accept(UCallExpression.kt:98)
    at org.jetbrains.uast.UQualifiedReferenceExpression.accept(UQualifiedReferenceExpression.kt:34)
    at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
    at org.jetbrains.uast.UBlockExpression.accept(UBlockExpression.kt:21)
    at org.jetbrains.uast.ULambdaExpression.accept(ULambdaExpression.kt:40)
    at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
    at org.jetbrains.uast.UCallExpression.accept(UCallExpression.kt:98)
    at org.jetbrains.uast.UQualifiedReferenceExpression.accept(UQualifiedReferenceExpression.kt:34)
    at org.jetbrains.uast.UBinaryExpression.accept(UBinaryExpression.kt:43)
    at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
    at org.jetbrains.uast.UBlockExpression.accept(UBlockExpression.kt:21)
    at org.jetbrains.uast.UMethod.accept(UMethod.kt:45)

3. local variable inside a lambda

    at org.jetbrains.uast.UBlockExpression.accept(UBlockExpression.kt:21)
    at org.jetbrains.uast.UMethod.accept(UMethod.kt:45)
    at com.android.tools.lint.client.api.AnnotationHandler.checkContextAnnotations(AnnotationHandler.kt:214)
    at com.android.tools.lint.client.api.AnnotationHandler.visitVariable(AnnotationHandler.kt:1082)
    at com.android.tools.lint.client.api.UElementVisitor$DelegatingUastVisitor.visitVariable(UElementVisitor.kt:840)
    at org.jetbrains.uast.visitor.UastVisitor.visitField(UastVisitor.kt:17)
    at com.android.tools.lint.client.api.UElementVisitor$DispatchUastVisitor.visitField(UElementVisitor.kt:478)
    at org.jetbrains.uast.kotlin.KotlinUField.accept(KotlinUField.kt:57)
    at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
    at org.jetbrains.uast.kotlin.AbstractKotlinUClass.accept(AbstractKotlinUClass.kt:213)
    at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
    at org.jetbrains.uast.UDeclarationsExpression.accept(UDeclarationsExpression.kt:22)
    at org.jetbrains.uast.internal.ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
    at org.jetbrains.uast.UBlockExpression.accept(UBlockExpression.kt:21)

However, all these cases look strange because my understanding is that, from b/247025215 and its unit test (added at https://cs.android.com/android-studio/platform/tools/base/+/8654cf2fb95104d184a79766b4032cb8b38f9da3:lint/libs/lint-tests/src/test/java/com/android/tools/lint/checks/ResourceTypeDetectorTest.kt;dlc=fc18c17c89607ae11b6f202a4db16edda1522b6c):

fun foo(@Anno param: Type) {
  ...
  dontCallMeWithAnnoedParam(param)
  ...
}

AnnotationHandler#visitVariable arrives at param as function's value parameter; goes up to its containing function foo; visits all name references in that function to see the variable usage and check if there is any violation w.r.t. the context annotation on the variable.

That is, the above call stacks look to me like:

fun containingFun(/* no arg! */) {
  ...
  try {
    blahblah = someNameToResolve + resolveMeToo
    ...
  } catch (@Anno e: SomeException) {
    ... // hm... what if dontCallMeWithAnnoedParam(e) here?
  }
}

or

fun <T> foo(arg: T, action: (@Anno T) -> Unit): action(arg)

fun containingFun(...) {
  blahblah = someNameToResolve + noWayToSeeLambdaArg
  foo(x) { lambdaArg -> // @Anno on lambdaArg?
    ...
    object : SomeAbstractClass {
      @Anno
      val reallyLocalInsideThisAnonymous = ... // but still go up to containingFun?
    }
    ...
  }
}

My naive attempt of filtering only function parameter discovered a case like this:

private void problem1() {
  @Tree int treeInvalid = 12;
  treeInvalid = 13;
  // annotations for variables or fields
  @Tree int treeValid = TREE_PATH_ONE;
  problem2(mTreeField); // Falsely marked as an error. Lint does not track @IntDef annotations
                        // fields so it does not know the mTreeField is actually a @Tree
}

So... I can see two inefficient things: 1) AnnotationHandler visits problem1 twice, one for treeInvalid and the other for treeValid. (In general, we may visit the same function as many of its expressions as possible...) 2) then, in each visit, AnnotationHandler attempts to resolve all name references in the function body. Although resolution would be cached and reused for the next runs, I wonder this may cause a trouble like this. Or, at a minimum, say, in the above example, if only one variable is annotated, and if there are 10_000 other variables in the function body, we still need one single resolution, based on name comparison (and all the other 10_000 resolutions are simply waste of time/lock/etc).

Ideally, AnnotationHandler should queue what functions to visit; what variable usages to look up and why (i.e., context annotations); and trigger resolutions for only name-matched references.

Thank you for the reports.

1. Can you confirm the most recent version of Android Studio where the problem does NOT occur? (You mentioned "reverting back".) Can you attach idea.log (and any other diagnostic files) from this version with the same project and file open, so that we can compare? Is it the same machine? Do you have the same custom VM options?

2. Regarding custom VM options, it looks like you have 2048MB heap, but 4096MB is suggested. See: File -> Settings...; Appearance & Behavior > System Settings > Memory Settings; IDE max heap size: 4096MB.

Relevant lines from idea.log:

2024-12-17 10:39:59,377 [ 240500]   INFO - #com.android.tools.idea.memorysettings.MemorySettingsRecommendation - recommendation based on machine: 4096, on project: 2048

3. It looks like your Gradle home directory (usually something like C:\Users\username\.gradle\, containing directories like caches) is set to the JBR (JRE) directory. Could you set it to some other directory, and restart the machine? (Just to get rid of any Gradle daemons that might still be running.) And, actually, your Gradle JDK directory appears to be set to the JBR from an older version of Android Studio (C:/Program Files/Android Studio/Android Studio 2024.2.2.7/jbr). Could you change that to something else? Perhaps a manually installed JDK? Was your older (working) version of Android Studio also set up like this? (If you provide idea.log, we can check this.)

Relevant lines from idea.log:

2024-12-17 10:44:16,315 [ 497438]   INFO - #c.i.u.i.ProjectChangedFilesScanner - Retrieving changed during indexing files of Norva24 MSlam : 26961 to update, calculated in 871ms
2024-12-17 10:44:18,615 [ 499738]   INFO - #c.i.u.i.c.IndexUpdateRunner - Directory was passed for indexing unexpectedly: C:/Program Files/Android Studio/Android Studio 2024.3.1.4/jbr/caches/8.11.1/transforms/cac5fcb001dee8ef12dc85428f69e27d/transformed/core-1.15.0/jars/classes.jar!/
2024-12-17 10:44:18,615 [ 499738]   INFO - #c.i.u.i.c.IndexUpdateRunner - Directory was passed for indexing unexpectedly: C:/Program Files/Android Studio/Android Studio 2024.3.1.4/jbr/caches/8.11.1/transforms/586e626602bdedf163fabf9e54411655/transformed/annotation-experimental-1.4.1/jars/classes.jar!/

...

2024-12-17 10:44:22,080 [ 503203]   INFO - #o.j.p.g.GradleManager - Instructing gradle to use java from C:/Program Files/Android Studio/Android Studio 2024.2.2.7/jbr

4. I can't see any plugin info in your idea.log. Can you try disabling any non-bundled (downloaded) plugins?

5. Can you reproduce the problem on a different project, such a new project? Perhaps an open source project, like https://github.com/signalapp/Signal-Android ? If the problem does not occur, can you try copying the problematic file into the project (as best as possible, or in a new project, create a file with a similar structure) to see if the problem reproduces? (As far as I can tell, I cannot reproduce on Signal-Android, although the experience was quite bad until I increased the max heap size.)

6. Do you have co-workers or collaborators who encounter the same problem with the same project on a different machine? Or do you have another machine where you can try it (without importing or syncing any settings)?

7. Can you send a screenshot or video of what you are doing when it happens? Can you try removing/hiding any live edit, visual UI designers/previews, etc. (i.e. at the top right of the code editor, click the (left-most) code button) and see if the problem occurs just when looking at (and typing) Kotlin code (no other split windows with previews etc.)?

8. Can you try adding the following to the lint block in the build.gradle[.kts] file of the problematic module (app module or library module), such that checkOnly has one entry of "none" (and then do a Gradle sync). I believe this should effectively disable Lint from running. This is obviously not a permanent solution, but I want to see if there are still freezes even when Lint never runs.

android {
    ...
    lint {
        checkOnly += "none"
    }
}

With the above steps, I mostly want to eliminate the possibility that there is some problem that is causing certain caches/indexes to get recalculated every time the open (Kotlin) file is re-analyzed, hence leading to a very slow analysis. If it is something like this then the actual structure of the open file and stack traces that we have access to in the freeze reports don't really matter.

9. 7 Can you try enabling K2 mode? (File -> Settings...; Languages & Framework > Kotlin; tick "Enable K2 mode")

Regarding the file you have open (this is only relevant if the above does not fix the problem):

10. 8 Do you have a lot of annotated fields, parameters, and/or local variables (or a lot of references to one or two of these things) in the problematic file that you have open? What does it look like? Can you share the file, or even the project? If not, can you share a copy of the file with variable, package, function names etc. changed, so we can see the general structure of it, and so that we can try to reproduce locally? Or if you re-created a similar file in step (5), maybe share this with us?

It seems that I have not enough time now to follow up some points, but I will try to answer some:

Background: We mainly work in Flutter projects in Android Studio (for now AS2024.2.1.12), there we don't experience hangs at all, but some other minor issues. In Meerkat we experienced the hangs in this kotlin project at least from AS2024.3.1.4 on. This project (no.norva24.mslam) is a quite large under-ground-infrastructure system (tanks, pipes etc site under ground) managing maintanance like emptying of sludge and flushing pipes. It is programmed in kotlin, and is view based (non composable). This month we needed to do some maintanance on the system, and we like to be "in front" to harvest benefits of new things, and therefore are using the Canaries of Android Studio for this particular project.

The project uses a Room database, which is moderately complex, which may kick of some background processing in the IDE, but historically it hasn't have any influence in the IDE "flow".

1. The last time we did some major changes in this project was in March 2024, and we did NOT experience any hangs in the IDE using Canaries in March 2024.

2. I got a warning from the IDE that the memory size was too low for a week a go (or so), and justified that to 8192, and restart the IDE after that. There where no influence of that change, the hangs still occurred.

3. Will do this later

4. There are no non bundled plugins in this project. All existing plugins are bundled.

5. Will check creating new project later.

6. It just me working on this particular project, I have two computers on my office site, I'll do a test on the second one lateron. The home office is sadly off-line at the moment because of maintenance from the fiber deliverers (have been lost in the fiber darkness for there for 16 days... ...a complicated matter)

7. Will work in the project today, and I will try to catch a screen-film for you.

8. I will check that later.

9 (7). I'll try that actually today.

10 (8). I can't tell if there is a particular file which the issue occurres, but rather WHAT the IDE want's to do. And yes, I want to share the project with you. Please send me a PM and I may invite you to download it from github.

As you see, have some data for you on point 1, 2, 4, 6.

The rest we need to do a followup on.

I can reproduce the freezes. It appears to simply be inefficient code in AnnotationHandler.checkContextAnnotations called by AnnotationHandler.visitVariable (and there are no calls to checkCanceled within this; I thought UAST visitors had implicit calls to checkCanceled, but I guess not).

I am not certain why performance regressed; I notice we are visiting a lot of implicit receiver parameters of lambdas, which perhaps wasn't happening before, and/or perhaps the nullness annotations from these implicit parameters were not previously getting returned. It is slightly unfortunate that we have one built in Lint check (KotlinNullnessAnnotationDetector) that declares any Nullable or NotNull annotations as "relevant", but of course does not actually care about any of the complex cases handled by AnnotationHandler (it would suffice to just visit any annotations explicitly in the source file). In fact, I somehow doubt that visitVariable was intended to trigger on fields (and maybe even parameters). Regardless, I think the bigger issue is that we are re-visiting parts of the AST (sometimes far too much) when we encounter a variable in order to find all the references, even though we already visit the references via the overall visitor.

Jinseong has already provided a fix that I believe improves things: https://cs.android.com/android-studio/platform/tools/base/+/004b4e5e7132146685a118072778beb16d1a57d4

As hinted at above, I think we can do even better by avoiding this revisiting, but it comes with some risks (behavior changes and different perf challenges). For now, I think Jinseong fix helps a lot; I will make use of the ability to reproduce the issue to: (1) add checkCanceled calls to prevent freezes and (2) create a test with a lot of lambdas, etc. that also leads to similarly bad performance. I'll create additional issues for the potential perf improvements.

I was wrong; this is not just a Lint perf issue (although the Lint perf does need to be improved).

The IntelliJ platform has changed such that Android Lint now runs in a non-cancelable section, which means the UI is essentially always frozen while Lint is running.

Filed bug upstream: https://youtrack.jetbrains.com/issue/IJPL-174400

Will just mention that AS2023.3.1.7 is better than previous versions, it doesn't hang in the same way (10-50 secs), it is now sporadically up to 5-7 seconds, but I see that context highlighting (and lint?) are lacking behind with 10secs up to 60 secs (worst cases may be more). If you did any changes for this version, it hasn't been to the worse though, a little better.

Happy new year and keep on the good work !

a fix that I believe improves things: https://cs.android.com/android-studio/platform/tools/base/+/004b4e5e7132146685a118072778beb16d1a57d4

This is supposed to be in 24.3.1.7, and it sounds like it indeed improved things a little bit. :)

We are in AS 2024.3.2.1 now, there are still intermittent hangs, but not as severe as it was in 2024.3.1.4, now they appears mostly when editing Room SQL code (which is an annotation), but there are still incidents when editing ordinary kotlin code, and also when editing the XML files.

From my perspective (if it counts, I may not understand the core problem as much), but why aren't handling of editors done in a separate thread, isolated from those who are handling lints, and backed code generation ? For us it is most important that the response if the editor (caret moving, typing, copy/cut/paste) must be have first priority!, and thereafter colorization and suggestions, and let them blend in as smoothly as possible, and you could give a "readiness %" score, if the programmer needs to "wait" for the backend to finish some editor handling from the backend.

Anyway, a little bit better here in 2024.3.2.1, but still not quite there.

An observation: When the editor hangs, my processor fan speeds up significantly (it's a HP ZBOOK Core i7, something) until it releases, and it eases down. May this be that the processes which are started runs on the GPU not the CPU ? (Just curius).

For some (strange) reason AS2024.3.2.2 is worse than AS2024.3.2.1 ...

Attaching log for this Saturday morning...

Fixes are in, landing in upcoming versions AS Meerkat.1 RC1 and AS Meerkat.2 Canary 3.

• Fix on the Android plugin side: https://android.googlesource.com/platform/tools/adt/idea/+/b5bba2de68
• Fix on the IntelliJ Platform side: https://android.googlesource.com/platform/tools/idea/+/94589709cb
• Regression test: https://android.googlesource.com/platform/tools/adt/idea/+/04f7bc14b7

Please add a comment with logs if you see this issue again (in the newer AS releases). Thanks!

why aren't handling of editors done in a separate thread, isolated from those who are handling lints

For posterity: edits and lints are handled in separate threads, but IntelliJ Platform uses a single global read/write lock to protect code-related data structures---meaning that long "reads" can block edits, manifesting as a UI freeze. This is an old design decision of IntelliJ Platform, going back a couple decades now. The usual way to avoid UI freezes in IntelliJ is to make reads "cancelable", such that pending edits will abort any in-progress reads and reschedule them for later (similar to what some databases do amid lock contention).

Android Lint is designed to be cancelable in this way, but a regression upstream in IntelliJ Platform meant that Lint accidentally ran in a non-cancellable section, hence this bug.

(Additionally, JetBrains has been working on mitigating the read/write lock pitfalls more generally, e.g. allowing reads to occur on a slightly outdated editor document without blocking direct edits from the user. But this is work-in-progress.)

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 Meerkat Feature Drop | 2024.3.2 Canary 3
• Android Gradle Plugin 8.10.0-alpha03

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!

The fixes for this issue are now also available in:

• Android Studio Meerkat | 2024.3.1 RC 1
• Android Gradle Plugin 8.9.0-rc01

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Just blending in to say that (AS2024.3.1.11 the little I have tested there and) AS2024.3.2.3 is now working much smoother editing in kotlin/views, allthough sometimes the colorizing and suggestion lags some seconds here and there, are theese the best ones so far !!

Good work, and keep up the good spirit !