Thanks for confirming! The fix will be in the next release of Lifecycle (2.5.0-beta01).

I am seeing a high occurance rate with 2.5.0-beta01 as well.

Re comment#5 and comment#6 - please file a new bug with a sample project that reproduces your issue. That would help rule out it being a duplicate of this issue where your remember around getBackStackEntry needs to be updated.

Please file a new bug with a minimal sample project that reproduces your error.

Re comment#10 - backQueue is not part of the public API surface and never has been. Calling anything on that is always, always, always the wrong thing to do.

Any updates? This issue is persistent for almost 6 months and its getting crazier.

It's still happening with navigation-compose 2.7.0 and lifecycle 2.6.1

Try 2.7.1

Still happening on navigation-compose v2.7.7 / lifecycle v2.7.0. Any updates / prospect? Workaround maybe?

Considering there is a workaround (to allow-list this file) moving this to I beta blocking.

Bingran asked me if I had any insights about this issue and mentioned that Aurimas didn't manage to reproduce it locally and suspected that it only happened in an incremental build.

I'm still investigating, but I notice a non-incremental build that failed on Aurimas's change from Comment #14 too:

https://android-build.corp.google.com/artifact/pending/P60996184/androidx_compose_multiplatform/latest/view/logs%2Fbuild_error.log

for

https://android-review.git.corp.google.com/c/platform/frameworks/support/+/2704399/1?checksPatchset=1&tab=checks

Also interesting, that non-incremental log from Comment #14 ( https://android-build.corp.google.com/artifact/pending/P60996184/androidx_compose_multiplatform/latest/view/logs%2Fbuild_error.log ) says:

'../../out/.gradle/.android/analytics.settings' has been created

rather than just modified

In terms of #20, I think that is expected because we normally see config cache miss if a file is created during configuration. However, if a file get modified, I assume it would say xxx has been modified.

I checked some timestamps again in aosp/2731437

Gradle started at 21:01:18 UTC 2023

Gradle completed at 21:07:21 UTC 2023

analytics.settings created at 21:05:35.748195543

4m17s after Gradle started

1m46s before Gradle ended

Uploaded the scan to https://ge.androidx.dev/s/zsuj6it4dvngu/timeline?end=1693516039451&page=39&start=1693515904743

I see a few tasks running in that scan around 4m17s, mostly but not exclusively lint

I just tried this command:

  OUT_DIR=../../out DIST_DIR=../../out/dist ./busytown/androidx_compose_multiplatform.sh

and found that that reproduced the error on my computer. Maybe we can simplify it from there

I see a few tasks running in that scan around 4m17s, mostly but not exclusively lint

I took a look at my previous lint fix after seeing this.

I think the problem might be that LintClient.isGradle might not always be true when running the lint tasks, in which case this fix doesn't work.

LintClient.isGradle should be true when running lint tasks from Gradle because we invoke lint with --client-id gradle, but when I run grep -r "client=\"" on the AndroidX codebase, I see a mix of client="gradle" and client="cli", which suggests to me that the client id is being reset in some cases.

I ran this command:

  rm ../../out -rf && OUT_DIR=../../out DIST_DIR=../../out/dist ./gradlew lintAnalyzeDebug -Pandroidx.verifyUpToDate 

and it created ../../out/.gradle/.android/analytics.settings

but when I ran this command

  rm ../../out -rf && OUT_DIR=../../out DIST_DIR=../../out/dist ./gradlew lintAnalyzeDebug -Pandroidx.verifyUpToDate --max-workers 1

it didn't create ../../out/.gradle/.android/analytics.settings

so it could be that reproducing the error requires running certain tasks at the same time

Combining Comment #25 and (sometimes lint reports being the wrong client) and Comment #26 (reproducing the issue seems to require parallelism), perhaps for the lint client to be wrong requires multiple tasks running at once.

I think lint runs inside the Gradle Daemon JVM process - is that right?

I notice LintClient.kt mentions “@JvmStatic lateinit var clientName: String”. I think that means multiple lint clients might be able to overwrite each others’ values?

Maybe I can figure out which tasks set the lint client to something else

Thanks for the insights Jeff!

I suspect the root cause is that lint itself sets this value multiple times from a single invocation. See here and here.

I'll write a fix for this.

I'll write a fix for this.

The fix is here. It will be in AGP 8.3.0-alpha03 and 8.2.0-beta04.

Thanks!

I investigated a little bit more into the plausibility of our guess (parallel lint invocations causing incorrect client) and it seems to be holding up:

1: I notice that aosp/2724176 changes some clients from "cli" to "gradle" for example https://android-review.git.corp.google.com/c/platform/frameworks/support/+/2724176/5/camera/integration-tests/coretestapp/lint-baseline.xml and also changes some clients from "gradle" to "cli" for example https://android-review.git.corp.google.com/c/platform/frameworks/support/+/2724176/5/compose/ui/ui/lint-baseline.xml

2: I regenerated all of the lint baselines via echo | tee find -name lint-baseline.xml && ./gradlew updateLintBaseline --max-workers=1 and found that it put 'client="gradle"' into the resulting files

I'll check again later after updating to the corresponding AGP

Thanks again Jeff!

Reassigning back to Bingran assuming the lint issue has been resolved.

In our integration tests, there are cases(e.g. AnalyticsConfigurationCachingTest) we need to create this file, therefore you would get config cache miss. So it is intended that we still have an entry in ConfigurationCacheReportChecker.

Unfortunately, yes, this change makes AGP's check for the existence of the file compatible with configuration caching, but AnalyticsSettings is still interacting with the file in a way that is not compatible with configuration caching.

This has been fixed here. Fix will be in AGP 8.3.0-alpha04.

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 Hedgehog | 2023.1.1 Beta 4
• Android Gradle Plugin 8.2.0-beta04

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 Iguana | 2023.2.1 Canary 4
• Android Gradle Plugin 8.3.0-alpha04

We encourage you to try the latest update.

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

In Gradle 8.3 we are ignoring this file with the following in gradle.properties:

org.gradle.configuration-cache.inputs.unsafe.ignore.file-system-checks=**/.gradle/.android/analytics.settings

However, the AnalyticsService still breaks configuration on demand for some people:

> Failed to apply plugin 'com.android.internal.library'.
   > Accessing GradleBuildProject.Builder through AnalyticsConfiguratorService is not allowed after AnalyticsService is created.

We've found that setting "hasOptedIn":false," in ~.gradle/.android/analytics.settings fixes the issue.

Re: #35, that looks like Issue 270731522