Status Update
Comments
se...@team.bumble.com <se...@team.bumble.com> #2
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> #3
al...@google.com <al...@google.com> #4
al...@google.com <al...@google.com> #5
Reassigning based on history for bundleInside
. We should re-namespace e.g. shadowJar
these instead.
lp...@google.com <lp...@google.com> #6
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> #7
Also:
classpath conflict between different versions of lint checks
I think each lint jar should be loaded into its own classpath
So I don't think this would explain the issue here anyway
se...@team.bumble.com <se...@team.bumble.com> #8
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> #9
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> #10
Nope, only Compose Lint checks are failing this way.
as...@google.com <as...@google.com> #11
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> #12
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> #13
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.
lp...@google.com <lp...@google.com> #14
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
lp...@google.com <lp...@google.com> #15
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> #16
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
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
Description
Jetpack Compose version: 2024.12.01
Android Studio Build: AGP 8.8.0
Kotlin version: 2.0.21
SuspiciousModifierThen:
MultipleAwaitPointerEventScopes:
ReturnFromAwaitPointerEventScope:
ProduceStateDoesNotAssignValue: