kotlinx.coroutines: Android Lint Error 1.6.1 - Invalid package reference
I’m seeing the following Android lint error on 1.6.1:
../../../../../../.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/kotlinx-coroutines-core-jvm/1.6.1-native-mt/ee5d3def1a25e11bb9450ce73c7dd1d8163ec856/kotlinx-coroutines-core-jvm-1.6.1-native-mt.jar: Error: Invalid package reference in org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm; not included in Android: java.lang.instrument. Referenced from kotlinx.coroutines.debug.AgentPremain. [InvalidPackage]
Explanation for issues of type "InvalidPackage":
This check scans through libraries looking for calls to APIs that are not included in Android.
When you create Android projects, the classpath is set up such that you can only access classes in the API packages that are included in Android.
However, if you add other projects to your libs/ folder, there is no guarantee that those .jar files were built with an Android specific classpath, and in particular, they could be accessing unsupported APIs such as java.applet.
This check scans through library jars and looks for references to API packages that are not included in Android and flags these. This is only an error if your code calls one of the library classes which wind up referencing the unsupported package.
Looks very similar to #2004.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 5
- Comments: 19 (4 by maintainers)
Commits related to this issue
- Suppress AgentPremain lint checks This file isn't used on Android but lint warns about invalid imports. More info here: https://github.com/Kotlin/kotlinx.coroutines/issues/3277 — committed to kirmanak/Mealient by kirmanak 2 years ago
- Fix build That's not used, but Android lint complains; For details: https://github.com/Kotlin/kotlinx.coroutines/issues/3277 — committed to Abrynos/ShoppingList by Abrynos 2 years ago
- Don't flag InvalidPackage errors in kotlinx-coroutines Bug: https://github.com/Kotlin/kotlinx.coroutines/issues/3277 Test: Unit test included Change-Id: Ib5a34ccea6cebdf3ab1694bf31cec86d60e64e71 — committed to Flank/mirror-goog-studio-main by tnorbye 2 years ago
Sorry for chiming in late – somebody pointed me to this discussion.
The reason adding @SuppressLint(“all”) on the source file for AgentPremain.kt in the kotlinx-coroutines-core library does not affect lint is that this only suppresses violations of that check in that source file.
The InvalidPackage check in lint actually looks at the bytecode of the libraries you’re calling. The backstory here is that early in Android, there were many Java libraries out there people tried to use which had not been written with Android in mind, so they may be using APIs not available in Android. So this lint check would go through the bytecode and for each API reference, check whether that API is present in Android and if not, warn.
That’s what’s happening here – it’s looking through the transitive dependencies, coming across the kotlinx-coroutines-library as one of the .jar files, and in its bytecode finding java.lang.instrument.*, which it then warns about. The @SuppressWarnings annotation is long since gone (and @SuppressWarnings has source retention); the bytecode is present, so it warns.
Note that this situation is not nearly the same anymore; at this point, there’s a wealth of Android libraries available that people are using for I/O, logging, etc. So this check isn’t nearly as useful as it once was – so, several years ago we actually turned it off by default. So if you’re running into violations of this check now, that means you’ve turned it on. I suspect you haven’t deliberately picked this check to turn on, but maybe you’re turning on all disabled checks by default (e.g. the -Wall flag, or android.lintOptions.checkAllWarnings in build.gradle). I don’t really want to delete the check; it’s still a thing people may want to audit for.
But we can probably make the check a bit smarter; in particular, perhaps we shouldn’t bother complaining about java.lang.instrument.* and just ignore those as probably being intended for conditional code.
The fix was in lint, not in this library – https://cs.android.com/android-studio/platform/tools/base/+/5c50b179631636311643428f78d3513d708a1da6 – which is fixed in Electric Eel canary (soon beta).
Thanks, I know of this workaround, I just wonder if this situation is an indicator of some actual bug.