Thank you for the report and the supplied dump with the reproduction. I can confirm that the NPE is also present on HEAD, and I will look into it.

Quite a few of the class files in the dump has malformed inner-class attribute, where R8 reports e.g.:

Info in /tmp/tmpo67ucguh/program.jar:ofifmwrrhhmodsc/ψξψξψξξ.class:
Malformed inner-class attribute:
	outerTypeInternal: ofifmwrrhhmodsc/ψξψξψξξ
	innerTypeInternal: ofifmwrrhhmodsc/ψξψξψξξ$ψξξψξξξ
	innerName: ψξψξψξξ$ψξξψξξξ

These are ignored, so they should not be the reason for the NPE, but something to also look into.

I will backport this to the 8.0 and 4.0 branches.

Thank you very much for taking a look at this!

Is this fix related to the nullpointer or the malformed inner-class attributes ?

Do you have a separated ticket for it? Could you share it?

Answer to #comment6. This fix only addresses the NPE.

The malformed inner-class attributes is an issue with the input class files, and they where not related to the NPE. You will have to contact the supplier of the library where they are present if you would like to get rid of the "Info" messages (you will have to run ./gradlew --info ... to see them). From what I can see the issue is that the innerName: ψξψξψξξ$ψξξψξξξ should have been innerName: ψξξψξξξ.

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