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.

Fixed, I need now to backport a bit.

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 Feature Drop | 2024.1.2 RC 1
• Android Gradle Plugin 8.6.0-rc01

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 Koala | 2024.1.1 Patch 2
• Android Gradle Plugin 8.5.2

We encourage you to try the latest update.

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

Hello, i encounter with similar issue in AGP 8.7.3 and R8 8.7.18:

    goto :goto_5b

    :cond_59
    move-object/from16 v15, p24

    :goto_5b
    const/high16 v16, 0x4000000

    and-int v0, v0, v16

    if-eqz v0, :cond_64

    const/16 v8, 0x0

    goto :goto_67

    :cond_64
    move-object/16 v264, p25
    ...
    move-object/from16 v2, v264

java.lang.VerifyError: Verifier rejected class:[0x430] copy1 v2<-v264 type=Undefined cat=3 

Re: comment#24: Please open a new issue at http://issuetracker.google.com/issues/new?component=317603.

In order to diagnose this issue, we would likely need a reproduction. If it would be possible for you to share a compiler dump, which contains the inputs to the D8 compilation, that should allow us to reproduce the issue. You can share this privately with christofferqa@google.com.

You can generate such a dump by running ./gradlew assembleRelease --no-daemon -Dcom.android.tools.r8.dumpinputtodirectory=/path/to/dumps.