Status Update
Comments
xi...@google.com <xi...@google.com>
ac...@google.com <ac...@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.
sa...@google.com <sa...@google.com> #3
Fixed by Change I7a57ba085bfd8c64679cf4bf3c05ce70da8cb5b8 using the InspectionSuppressor
EP.
ac...@google.com <ac...@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!
sa...@google.com <sa...@google.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
no...@google.com <no...@google.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.
sa...@google.com <sa...@google.com> #7
Android Studio Koala | 2024.1.1 Canary 7
Android Gradle Plugin 8.4
Gradle 8.7
Still an issue
ac...@google.com <ac...@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?
sa...@google.com <sa...@google.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.
ac...@google.com <ac...@google.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
sa...@google.com <sa...@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?
an...@google.com <an...@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).
Description
When using Profile/debug APK on macOS, trying to run the APK on the device / emulator fails when the APK name has spaces in it. I verified it works correctly when I renamed the APK to a simple name without spaces or " (1)".
In case it matters, I set up profiling on startup first, but I think regular Run also fails.
Log: