IssueTracker

Matthew, any thoughts on how best to do this? I know that we have the LanguageFeatureProvider abstraction in the Java plugin (and our own AndroidLanguageFeatureProvider which does API level checks) in order to silence a number of inspections. But this particular inspection (JavaApiUsageInspection) does not seem to reference any JavaFeatures, it unconditionally reports them.

Fixed by Change I7a57ba085bfd8c64679cf4bf3c05ce70da8cb5b8 using the InspectionSuppressor EP.

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 Koala | 2024.1.1 Canary 4
• Android Gradle Plugin 8.5.0-alpha04

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!

Android Studio Koala | 2024.1.1 Canary 4
Android Gradle Plugin 8.5.0-alpha04

does not work...

Objects.requireNonNullElse(

is still flagged as error

Gradle Plugin 8.5.0-alpha04 seems be very broken in fact. My project does not even deploy now due to missing classes in the dex. I tried invalidating caches, full rebuild, a fresh emulator install....

Reverting to 8.3.2 and all is well again.

Android Studio Koala | 2024.1.1 Canary 7
Android Gradle Plugin 8.4
Gradle 8.7

Still an issue

I'm not seeing this using the latest Koala canary and the above test case. Can you provide more instructions for how to reproduce what you're seeing?

No idea what is going on to be fair....

• a brand new project, and requireNonNullElse shows no problem.
• any existing project of mine (checked 4) show the problem.

However, it seems Gradle Plugin 8.4 is having the same problems as I saw with 8.5.0-alpha04. Missing classes in the dex / failures to build. The identical setup with Plugin 8.3.2 and all builds/deploys fine (except the RNNE warning obviously)

rant... each "upgrade" brings new problems.... I'll need to drop back to 8.3.2 AGAIN for now.

If/when eventually the gradle plugin decides to play nice again, I'll check the RNNE again.

ok - I managed to fix the AGP 8.4 upgrade issue.

Current setup: Koala canary 8 + AGP 8.4 + Gradle 8.7

Android Studio Koala | 2024.1.1 Canary 8 Build #AI-241.15989.150.2411.11792637, built on May 2, 2024 Runtime version: 17.0.10+8-b1207.12 amd64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. Windows 11.0 GC: G1 Young Generation, G1 Old Generation Memory: 12288M Cores: 20 Registry: ide.browser.jcef.testMode.enabled=true ide.browser.jcef.sandbox.enable=false ide.images.show.chessboard=true Non-Bundled Plugins: name.kropp.intellij.makefile (241.14494.150) artsiomch.cmake (241.1.1)

• a brand new project, and requireNonNullElse shows no problem.
• requireNonNullElse is still showing up as error in existing projects

Hm. Any other clues for how the two scenarios might be different? Do they have the same minSdkVersion? Is the usage in a library or in an app module? Is one of the projects using core library desugaring?

Actually, never mind, I was confusing this with the NewApi lint check where those things might matter -- they don't for this. But this is the IntelliJ inspection. The thing that matters there is whether the module which contains this violation is considered an Android module in the IDE. I think that's influenced by which Gradle plugins are applied in that module -- whether it's an Android module (library or app), or some other Gradle module (like a Java library).

Matthew, for lint's API check there's a similar issue with Java libraries -- we want API check to apply the minSdkVersion for the app module -- which may not be where we find an API call. So in the lint setup in the IDE we look for the first app module and pull the constraints from there.

I wonder if we should do the same thing here -- if there is any Android module in the project, we probably want to suppress the Java API inspections (since lint will kick in instead; the assumption is that these libraries will get consumed in the app and then processed by the Android tooling -- D8/R8, etc.)

I've got something I think :)

app/library: makes no difference.

desugaring: YES.... I added desugaring (2.0.4) to the test/new project, and it's now also flagging up RNNE as an error.

Hope this helps.

it's now also flagging up RNNE as an error

Can you hover over the error and check what the error text says? I just want to confirm that you're seeing the exact same issue as comment#1.

sure:

Call requires API level 30 (current min is 26): java.util.Objects#requireNonNullElse

Interesting, thanks! That has a slightly different root cause; this bug was originally about an error coming from an IntelliJ inspection, whereas your error seems to be a false positive coming from Android Lint. Let's continue investigating your scenario at https://issuetracker.google.com/327670482.

Re #18, unfortunately not

This issue is fixed in Jellyfish, which was released last week.

I'm still seeing this in stable Jellyfish with AGP v8.4.0..

Adding this to my settings.gradle.kts solved it just now.

gradle.startParameter.excludedTaskNames.addAll(listOf(":build-logic:convention:testClasses"))

Source: https://issuetracker.google.com/issues/315023802#comment23

Re: #22 and #23, can you please file a new bug with steps to reproduce the issue and link it here?

This issue is specifically for the case involving buildSrc. If you are seeing a similar error message without buildSrc, and it's not a KMP project (Issue 330294594), then it's probably a different root cause.

I have the same issue on Android Studio Ladybug | 2024.2.1. Excluding testClasses task has helped for now, but it seems like this bug is still there.

Re: #26, can you please file a new bug with steps to reproduce the issue and link it here?

I'm still facing this issue in Android Studio Ladybug Feature Drop | 2024.2.2 with AGP 8.8.0 and Gradle 8.10.2

Still using this workaround since Android Studio Iguana | 2023.2.1 Patch 1 and 2 with Gradle 8.4 and AGP 8.3.1:

In top level settings.gradle add: gradle.startParameter.excludedTaskNames.addAll([":gradle:testClasses"])

See Gradle issue here: https://github.com/gradle/gradle/issues/28407

Re: #28, this bug and its fix are specific to the ":buildSrc:testClasses" task, so it sounds like you're hitting a different bug. Can you file a separate issue with repro steps?