AGP 7.0.0-alpha13: lint task fails

[ubuntudroid]

When running the lint task with AGP 7.0.0-alpha13 it will fail with the following error:

The lint detector
timber.lint.WrongTimberUsageDetector
called context.getMainProject() during module analysis.

This does not work correctly when running in cli.

In particular, there may be false positives or false negatives because
the lint check may be using the minSdkVersion or manifest information
from the library instead of any consuming app module.

Contact the vendor of the lint issue to get it fixed/updated (if
known, listed below), and in the meantime you can try to work around
this by disabling the following issues:

"LogNotTimber","StringFormatInTimber","ThrowableNotAtBeginning","BinaryOperationInTimber","TimberArgCount","TimberArgTypes","TimberTagLength","TimberExceptionLogging"

Issue Vendors:
Identifier: timber-4.7.1

Call stack: Context.getMainProject(Context.kt:117)
←WrongTimberUsageDetector.visitMethod(WrongTimberUsageDetector.java:80)
←Detector.visitMethodCall(Detector.kt:551)
←UElementVisitor$DelegatingPsiVisitor.visitMethodCallExpression(UElementVisitor.kt:1095)
←UElementVisitor$DelegatingPsiVisitor.visitCallExpression(UElementVisitor.kt:1075)
←KotlinUFunctionCallExpression.accept(KotlinUFunctionCallExpression.kt:186)
←UQualifiedReferenceExpression$DefaultImpls.accept(UQualifiedReferenceExpression.kt:34)
←KotlinUQualifiedReferenceExpression.accept(KotlinUQualifiedReferenceExpression.kt:29)
←UQualifiedReferenceExpression$DefaultImpls.accept(UQualifiedReferenceExpression.kt:33)
←KotlinUQualifiedReferenceExpression.accept(KotlinUQualifiedReferenceExpression.kt:29)
←ImplementationUtilsKt.acceptList(implementationUtils.kt:23)
←UBlockExpression$DefaultImpls.accept(UBlockExpression.kt:21)
←KotlinUBlockExpression.accept(KotlinUBlockExpression.kt:24)
←ULambdaExpression$DefaultImpls.accept(ULambdaExpression.kt:33)
←KotlinULambdaExpression.accept(KotlinULambdaExpression.kt:29)
←ImplementationUtilsKt.acceptList(implementationUtils.kt:23)
←KotlinUFunctionCallExpression.accept(KotlinUFunctionCallExpression.kt:190)
←UQualifiedReferenceExpression$DefaultImpls.accept(UQualifiedReferenceExpression.kt:33)
←KotlinUQualifiedReferenceExpression.accept(KotlinUQualifiedReferenceExpression.kt:29)
←ImplementationUtilsKt.acceptList(implementationUtils.kt:23)

Everything works fine when using AGP 7.0.0-alpha12. Disabling the issues obviously works as a temporary workaround.

[pablisco]

Upgrading our AGP to alpha-14 seems to have solved this issue for us

[ubuntudroid]

@pablisco Thanks for the heads-up! Unfortunately I can't try this out right now as we can't update to alpha-14 just yet. Will report back as soon as I can do the update.

[dschwemleinST]

I am seeing this error with both AGP alpha-13 and alpha-14. It was fine with alpha-12. Can work around it with android.enableParallelLint=false in gradle.properties.

[ubuntudroid]

@pablisco @dschwemleinST for me it works just fine again with alpha-14 even without enableParallelLint=false. So I'd like to close this issue. Please double check, @dschwemleinST and confirm that it really doesn't work for you after a clean build.

[dschwemleinST]

@ubuntudroid Thank you for following up! It does appear to work after a few clean/builds using alpha-14 without enableParallelLint=false.

[ubuntudroid]

My bad, I didn't test on CLI/CI. 🤦 There it still does not work. So I have to keep the issue open. 😞 android.enableParallelLint=false indeed does work as a workaround though.

[ubuntudroid]

@dschwemleinST That's interesting. I can confirm, that cleaning fixes things locally. However on CI it still doesn't work despite cleaning all caches... 🤔

[dschwemleinST]

@ubuntudroid Exact same behavior here - it worked locally but once it failed on CI I removed my comment because I thought I must have been mistaken. So for now I am using alpha14 with the android.enableParallelLint=false workaround.

[ubuntudroid]

Very confusing. Even adding a gradle clean to the CI build workflow didn't fix it there... I think I'll disable Timber lint checks for now, as disabling parallel lint in general would slow down builds on all machines and the Timber checks are mostly geared towards new Timber users anyway.

[NitroG42]

As it seems the error happened with alpha13-14, I made a reported the bug on the APG side => https://issuetracker.google.com/issues/184565320 But without answer for now.

[NitroG42]

Last follow up, as it seems the issue escalated!

It is an issue that needs to be fixed in Timber, yes. Timber will need to be updated to be compatible with Lint / AGP 7.0.

[mengdd]

Found the reason might due to getMainProject: See: http://googlesamples.github.io/android-custom-lint-rules/api-guide.md.html For this section: Catching Mistakes: Blocking Access to Main Project

[Mehly]

I'm still experiencing this issue with:

// Android Gradle Plugin 7.0.0-beta04:
classpath 'com.android.tools.build:gradle:7.0.0-beta04'

// Timber 4.7.1:
implementation 'com.jakewharton.timber:timber:4.7.1'

[eygraber]

Getting https://github.com/JakeWharton/timber/pull/410 merged would probably be a step in the right direction (I suppose I should clean up some of the deploy stuff :thinking: ).

Should make it easier to update to AGP 7.0.0 when it is stable (unless doing it pre stable is OK in which case I would just do that).

[petedoyle]

Probably a red herring- I updated to AGP/lint 7.0.0-beta03 a few days ago and it's worked fine on both MacOS and Linux/CI (where every build gets a clean container.)

However, I just tried disabling Jetifier (our project is finally there 🙌) and this popped up. FYI in case it's related.

[AlanChiou]

I have this issue with AGP 7.0.0.

    classpath "com.android.tools.build:gradle:7.0.0"
    implementation 'com.jakewharton.timber:timber:4.7.1'

[eygraber]

There are a few PRs waiting to be merged that should fix this.

[mohsenoid]

Any update on this issue?

[arlindiDev]

Im guessing we have to wait until this commit gets released. Here is the PR (already merged) for that commit.

From the Android Lint API guide, the section:

8.4.1 Catching Mistakes: Blocking Access to Main Project

states that using getMainProject() will fail with that error that we are seeing.

In that already merged PR, the change from using getMainProject() to getProject() should fix this issue? Here is the line of code that was changed to use getProject().

What is the difference between calling getMainProject() vs getProject()? Would the getProject().minSdkVersion() < 25 only be true/valid only for non application modules.

[JakeWharton]

Fix is merged but not yet released.