Status Update
Comments
tn...@google.com <tn...@google.com> #2
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.
gh...@google.com <gh...@google.com> #3
Fixed by Change I7a57ba085bfd8c64679cf4bf3c05ce70da8cb5b8 using the InspectionSuppressor
EP.
an...@google.com <an...@google.com> #4
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!
to...@yahoo.com <to...@yahoo.com> #5
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
to...@yahoo.com <to...@yahoo.com> #6
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.
to...@yahoo.com <to...@yahoo.com> #7
Android Studio Koala | 2024.1.1 Canary 7
Android Gradle Plugin 8.4
Gradle 8.7
Still an issue
tn...@google.com <tn...@google.com> #8
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?
to...@yahoo.com <to...@yahoo.com> #9
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.
to...@yahoo.com <to...@yahoo.com> #10
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
tn...@google.com <tn...@google.com> #11
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?
tn...@google.com <tn...@google.com> #12
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).
tn...@google.com <tn...@google.com> #13
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.)
to...@yahoo.com <to...@yahoo.com> #14
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.
to...@yahoo.com <to...@yahoo.com> #16
sure:
Call requires API level 30 (current min is 26): java.util.Objects#requireNonNullElse
gh...@google.com <gh...@google.com> #17
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
Description
If you create a Java class like this:
the IDE will show an error underline under the requireNonNullElse call. This is not coming from lint, it's a builtin Java inspection which says that this is a "Usage of API documented as @since 9+". This is not the case in Android -- and we have our own API inspection in lint (NewApi) which handles it more accurately (with API levels, looking for surrounding version checks etc -- and in the above case -- also consulting which methods are automatically desugared by R8 -- this is one of them).
We basically shouldn't be running this inspection in the IDE.