Sporadic Lint crashes on multiple Compose Runtime Lint rules (NoClassDefFoundError) [395489602]

Assigned

Bug

Status Update

No update yet.

Description

se...@team.bumble.com

created issue #1

Feb 10, 2025 03:20PM

Jetpack Compose version: 2024.12.01
Android Studio Build: AGP 8.8.0
Kotlin version: 2.0.21

SuspiciousModifierThen:

Message: Unexpected failure during lint analysis (this is a bug in lint or one of the libraries it depends on)
  
Message: androidx/compose/ui/lint/SuspiciousModifierThenDetectorKt
  
The crash seems to involve the detector \\\`androidx.compose.ui.lint.SuspiciousModifierThenDetector\\\`.
You can try disabling it with something like this:
    android {
        lint {
            disable "SuspiciousModifierThen"
        }
    }

NoClassDefFoundError:SuspiciousModifierThenDetector$visitMethodCall$1.visitCallExpression(SuspiciousModifierThenDetector.kt:81)
UCallExpression.accept(UCallExpression.kt:94)
SuspiciousModifierThenDetector.visitMethodCall(SuspiciousModifierThenDetector.kt:65)
UElementVisitor$DelegatingUastVisitor.visitMethodCallExpression(UElementVisitor.kt:780)
UElementVisitor$DelegatingUastVisitor.visitCallExpression(UElementVisitor.kt:761)
UCallExpression.accept(UCallExpression.kt:94)
UQualifiedReferenceExpression.accept(UQualifiedReferenceExpression.kt:34)
UReturnExpression.accept(UReturnExpression.kt:22)
ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
UBlockExpression.accept(UBlockExpression.kt:21)
UMethod.accept(UMethod.kt:45)
ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
AbstractKotlinUClass.accept(AbstractKotlinUClass.kt:213)
ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
UFile.accept(UFile.kt:89)
UastLintUtilsKt.acceptSourceFile(UastLintUtils.kt:953)
UElementVisitor.visitFile$lambda$5(UElementVisitor.kt:216)
LintClient.runReadAction(LintClient.kt:1781)
LintDriver$LintClientWrapper.runReadAction(LintDriver.kt:2747)
UElementVisitor.visitFile(UElementVisitor.kt:213)
LintDriver.visitUastDetectors$lambda$42(LintDriver.kt:2048)
LintClient.runReadAction(LintClient.kt:1781)
LintDriver$LintClientWrapper.runReadAction(LintDriver.kt:2747)
LintDriver.visitUastDetectors(LintDriver.kt:2048)
LintDriver.visitUast(LintDriver.kt:2010)
LintDriver.runFileDetectors(LintDriver.kt:1284)
LintDriver.checkProject(LintDriver.kt:1070)
LintDriver.checkProjectRoot(LintDriver.kt:622)
LintDriver.access$checkProjectRoot(LintDriver.kt:174)
LintDriver$analyzeOnly$1.invoke(LintDriver.kt:445)
LintDriver$analyzeOnly$1.invoke(LintDriver.kt:442)
LintDriver.doAnalyze(LintDriver.kt:501)
LintDriver.analyzeOnly(LintDriver.kt:442)
LintCliClient$analyzeOnly$1.invoke(LintCliClient.kt:259)
LintCliClient$analyzeOnly$1.invoke(LintCliClient.kt:256)
LintCliClient.run(LintCliClient.kt:313)
LintCliClient.analyzeOnly(LintCliClient.kt:256)

MultipleAwaitPointerEventScopes:

Message: Unexpected failure during lint analysis (this is a bug in lint or one of the libraries it depends on)	
Message: androidx/compose/lint/Names$Ui$Pointer	
The crash seems to involve the detector \`androidx.compose.ui.lint.MultipleAwaitPointerEventScopesDetector\`.	
You can try disabling it with something like this:	
    android {	
        lint {	
            disable "MultipleAwaitPointerEventScopes"	
        }	
    }

NoClassDefFoundError:MultipleAwaitPointerEventScopesDetector.getApplicableMethodNames(MultipleAwaitPointerEventScopesDetector.kt:46)
UElementVisitor.<init>(UElementVisitor.kt:158)
LintDriver.visitUast(LintDriver.kt:2008)
LintDriver.runFileDetectors(LintDriver.kt:1284)
LintDriver.checkProject(LintDriver.kt:1070)
LintDriver.checkProjectRoot(LintDriver.kt:622)
LintDriver.access$checkProjectRoot(LintDriver.kt:174)
LintDriver$analyzeOnly$1.invoke(LintDriver.kt:445)
LintDriver$analyzeOnly$1.invoke(LintDriver.kt:442)
LintDriver.doAnalyze(LintDriver.kt:501)
LintDriver.analyzeOnly(LintDriver.kt:442)
LintCliClient$analyzeOnly$1.invoke(LintCliClient.kt:259)
LintCliClient$analyzeOnly$1.invoke(LintCliClient.kt:256)
LintCliClient.run(LintCliClient.kt:313)
LintCliClient.analyzeOnly(LintCliClient.kt:256)

ReturnFromAwaitPointerEventScope:

Message: Unexpected failure during lint analysis (this is a bug in lint or one of the libraries it depends on)	
Message: androidx/compose/lint/Names$Ui$Pointer	
The crash seems to involve the detector \`androidx.compose.ui.lint.ReturnFromAwaitPointerEventScopeDetector\`.	
You can try disabling it with something like this:	
    android {	
        lint {	
            disable "ReturnFromAwaitPointerEventScope"	
        }	
    }

NoClassDefFoundError:ReturnFromAwaitPointerEventScopeDetector.getApplicableMethodNames(ReturnFromAwaitPointerEventScopeDetector.kt:42)
UElementVisitor.<init>(UElementVisitor.kt:158)
LintDriver.visitUast(LintDriver.kt:2008)
LintDriver.runFileDetectors(LintDriver.kt:1284)
LintDriver.checkProject(LintDriver.kt:1070)
LintDriver.checkProjectRoot(LintDriver.kt:622)
LintDriver.access$checkProjectRoot(LintDriver.kt:174)
LintDriver$analyzeOnly$1.invoke(LintDriver.kt:445)
LintDriver$analyzeOnly$1.invoke(LintDriver.kt:442)
LintDriver.doAnalyze(LintDriver.kt:501)
LintDriver.analyzeOnly(LintDriver.kt:442)
LintCliClient$analyzeOnly$1.invoke(LintCliClient.kt:259)
LintCliClient$analyzeOnly$1.invoke(LintCliClient.kt:256)
LintCliClient.run(LintCliClient.kt:313)
LintCliClient.analyzeOnly(LintCliClient.kt:256)

ProduceStateDoesNotAssignValue:

Message: Unexpected failure during lint analysis (this is a bug in lint or one of the libraries it depends on)	

Message: androidx/compose/runtime/lint/ProduceStateDetector$visitMethodCall$1	
The crash seems to involve the detector \\\`androidx.compose.runtime.lint.ProduceStateDetector\\\`.	
You can try disabling it with something like this:	
    android {	
        lint {	
            disable "ProduceStateDoesNotAssignValue"	
        }	
    }

NoClassDefFoundError:ProduceStateDetector.visitMethodCall(ProduceStateDetector.kt:69)
UElementVisitor$DelegatingUastVisitor.visitMethodCallExpression(UElementVisitor.kt:780)
UElementVisitor$DelegatingUastVisitor.visitCallExpression(UElementVisitor.kt:761)
UCallExpression.accept(UCallExpression.kt:94)
UReturnExpression.accept(UReturnExpression.kt:22)
ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
UBlockExpression.accept(UBlockExpression.kt:21)
UMethod.accept(UMethod.kt:45)
ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
AbstractKotlinUClass.accept(AbstractKotlinUClass.kt:213)
ImplementationUtilsKt.acceptList(implementationUtils.kt:15)
UFile.accept(UFile.kt:89)
UastLintUtilsKt.acceptSourceFile(UastLintUtils.kt:953)
UElementVisitor.visitFile$lambda$5(UElementVisitor.kt:216)
LintClient.runReadAction(LintClient.kt:1781)
LintDriver$LintClientWrapper.runReadAction(LintDriver.kt:2747)
UElementVisitor.visitFile(UElementVisitor.kt:213)
LintDriver.visitUastDetectors$lambda$42(LintDriver.kt:2048)
LintClient.runReadAction(LintClient.kt:1781)
LintDriver$LintClientWrapper.runReadAction(LintDriver.kt:2747)
LintDriver.visitUastDetectors(LintDriver.kt:2048)
LintDriver.visitUast(LintDriver.kt:2010)
LintDriver.runFileDetectors(LintDriver.kt:1284)
LintDriver.checkProject(LintDriver.kt:1070)
LintDriver.checkProjectRoot(LintDriver.kt:622)
LintDriver.access$checkProjectRoot(LintDriver.kt:174)
LintDriver$analyzeOnly$1.invoke(LintDriver.kt:445)
LintDriver$analyzeOnly$1.invoke(LintDriver.kt:442)
LintDriver.doAnalyze(LintDriver.kt:501)
LintDriver.analyzeOnly(LintDriver.kt:442)
LintCliClient$analyzeOnly$1.invoke(LintCliClient.kt:259)
LintCliClient$analyzeOnly$1.invoke(LintCliClient.kt:256)
LintCliClient.run(LintCliClient.kt:313)
LintCliClient.analyzeOnly(LintCliClient.kt:256)

Comments

se...@team.bumble.com <se...@team.bumble.com> #2Feb 10, 2025 03:30PM

This actually has nothing to do with NavHostFragment, but is the behavior of NavController's setGraph().

When you call navController.setGraph(R.navigation.navigation_graph), it stores that ID and will restore that ID automatically.

If you were to instead use:

NavInflater navInflater = new NavInflater(this, navController.getNavigatorProvider());
navController.setGraph(navInflater.inflate(R.navigation.navigation_graph));

Then NavController would not restore the graph itself and the call to restoreState() you point out would only restore the back stack state, etc. but would wait for you to call setGraph again.

You're right that the inconsistency between the two setGraph methods is concerning. We'll take a look.

al...@google.com <al...@google.com> #3Feb 13, 2025 10:39PM

Reassigned to an...@google.com.

Turns out, we already had a tracking bug for this issue, will follow up on that other one.

al...@google.com <al...@google.com> #4Feb 13, 2025 10:41PM

Reassigned to lp...@google.com.

Thank you for promptly replying to my report. You are right that the issue you've just mentioned is similar to mine. I shall continue observing the progress over there.

al...@google.com <al...@google.com> #5Feb 13, 2025 10:42PM

Reassigning based on history for bundleInside. We should re-namespace e.g. shadowJar these instead.

lp...@google.com <lp...@google.com> #6Feb 14, 2025 05:09AM

Triage notes: This is because we're using bundleInside for common lint utils and lint is getting a classpath conflict between different versions of lint checks. We need to fix the library build.

Alan, could you clarify what you mean by this? For example in the first trace I see:

NoClassDefFoundError:SuspiciousModifierThenDetector$visitMethodCall$1.visitCallExpression(SuspiciousModifierThenDetector.kt:81)

where the class is

Message: androidx/compose/ui/lint/SuspiciousModifierThenDetectorKt - this class is in the same ui-lint jar, not part of the bundleInside utils we include. This is also defined in the same file (since it's the top level functions) as the detector that is failing, so I don't really understand how it's possible for SuspiciousModifierThenDetector to be loaded in the classpath but not SuspiciousModifierThenDetectorKt

lp...@google.com <lp...@google.com> #7Feb 14, 2025 05:28AM

Also:

classpath conflict between different versions of lint checks

I think each lint jar should be loaded into its own classpath

https://cs.android.com/android-studio/platform/tools/base/+/mirror-goog-studio-main:lint/libs/lint-api/src/main/java/com/android/tools/lint/client/api/JarFileIssueRegistry.kt;l=252

So I don't think this would explain the issue here anyway

se...@team.bumble.com <se...@team.bumble.com> #8Feb 14, 2025 09:09AM

We're using persistent Gradle daemons on CI. Is it possible that classloaders are cached in the daemon and affect subsequent builds?

lp...@google.com <lp...@google.com> #9Feb 14, 2025 05:23PM

It might be something related, but it's strange if it is only Compose lint checks. Do you have other lint checks that are failing in a similar way?

se...@team.bumble.com <se...@team.bumble.com> #10Feb 14, 2025 05:25PM

Nope, only Compose Lint checks are failing this way.

as...@google.com <as...@google.com> #11Feb 14, 2025 05:30PM

The NoClassDefFoundError seems to point to Names class from the compose/lint/common module which is bundled into every lint jar with bundleInside.

lp...@google.com <lp...@google.com> #12Feb 14, 2025 08:57PM

Did this start failing since a particular compose version upgrade / agp upgrade or similar? I don't think much has changed here in how these lint checks are bundled, and I haven't seen an issue like this before. Also for Jetpack Compose version: 2024.12.01 - is this being used for all libraries? Or is it possible that you have some libraries with different versions?

se...@team.bumble.com <se...@team.bumble.com> #13Feb 14, 2025 09:24PM

We recently updated AGP to 8.7+. Could this behaviour change in AGP 8.7 be the reason why we started seeing these failures?

Starting with Android Gradle Plugin 8.7.0-alpha08, if there is a LintError when running lint using Gradle, the lint analysis task throws an exception.

Also for Jetpack Compose version: 2024.12.01 - is this being used for all libraries?

I believe so. I'm attaching a screenshot with resolved versions of androidx.compose... libraries.

Screenshot 2025-02-14 at 21.21.13.png

357 KB

View

Download

lp...@google.com <lp...@google.com> #14Feb 25, 2025 12:12AM

We recently updated AGP to 8.7+. Could this behaviour change in AGP 8.7 be the reason why we started seeing these failures?

Did you also recently change Compose versions? Or you changed AGP without changing compose versions? There could be something that changed with AGP that caused this to start failing. If you could narrow this down to an AGP upgrade for example that would be helpful for us to investigate

Message last modified on Feb 25, 2025 12:12AM

lp...@google.com <lp...@google.com> #15Feb 25, 2025 12:14AM

Also, do you have some type of build caching / other caching between CI builds? Or should all the lint tasks be fully executed on each CI run?

se...@team.bumble.com <se...@team.bumble.com> #16Feb 26, 2025 07:03PM

Did you also recently change Compose versions? Or you changed AGP without changing compose versions?

We recently updated Compose from 1.6.x to 1.7.x because of b/330055201, and AGP from 8.6.x to 8.8.1. However, we had the same crashes with Compose 1.6.x.

do you have some type of build caching / other caching between CI builds? Or should all the lint tasks be fully executed on each CI run?

We run Lint on a different set of Gradle projects each build, depending on which projects are modified in the pull request. Gradle build cache and Gradle daemon are enabled, configuration cache is disabled.

Hope this helps