Unable to find common super type for <class_name> and <class_name> [231997058]

Fixed

Bug

Status Update

No update yet.

Description

ro...@sentry.io

created issue #1

May 10, 2022 10:04AM

Using the new Instrumentation API, I noticed that sometimes I have the following messages when the instrumentation transforms run (this is just one example of those):

Unable to find common super type for java/lang/Object and kotlin/coroutines/Continuation.
Unable to find common super type for kotlin/coroutines/Continuation and java/lang/Throwable.
Unable to find common super type for java/lang/reflect/Method and kotlin/Result$Companion.
Unable to find common super type for kotlin/KotlinNullPointerException and kotlin/coroutines/Continuation.

After checking the sources, I found out the warnings are being printed here, which gave me an impression that I cannot actually fix this on my site.

Some background on my instrumentation: I am looking at all classes (so not filtering anything in the isInstrumentable method) and then replacing some method calls with my static instrumented method calls. So I'd need those classes to be gone through the FixFramesClassWriter as well.

If there's nothing I can fix on my site, can this at least be an info or debug level log? It seems it doesn't affect the instrumentation or the runtime behavior of the app, so sounds like this can be avoided to pollute users' console log.

Studio Build: N/A Version of Gradle Plugin: 7.2 Version of Gradle: N/A Version of Java: 11 OS: N/A

Comments

lu...@google.com <lu...@google.com> May 10, 2022 10:05AM

Assigned to an...@google.com.

je...@google.com <je...@google.com> May 10, 2022 03:17PM

Reassigned to am...@google.com.

am...@google.com <am...@google.com> #2May 11, 2022 11:25AM

I also have the same issue so it seems to be a real problem.

ro...@sentry.io <ro...@sentry.io> #3May 11, 2022 03:48PM

Dup here:

http://code.google.com/p/android/issues/detail?id=27959&can=1&q=fixed%20position&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars

Though it's a bit more detailed with the minimum necessary to reproduce.

Message last modified on May 16, 2022 07:15AM

am...@google.com <am...@google.com> #4May 26, 2022 02:15PM

why is this marked has Obsolete? this is still a bug that is happening and its difficult to fix.
for all who are looking for a solution use this:

http://stackoverflow.com/questions/16200972/android-css-positionfixed-after-a-device-rotate

ro...@sentry.io <ro...@sentry.io> #5May 30, 2022 08:53AM

Alright, I've just tried to apply my plugin to now-in-android and this is the output I got:

Unable to find common super type for androidx/window/sidecar/SidecarDeviceState and androidx/window/sidecar/SidecarInterface.
Unable to find common super type for androidx/window/sidecar/SidecarDeviceState and androidx/window/sidecar/SidecarInterface.
Unable to find common super type for androidx/window/sidecar/SidecarInterface and java/lang/Object.
Unable to find common super type for androidx/window/sidecar/SidecarDeviceState and java/lang/Object.
Unable to find common super type for java/lang/Class and androidx/window/sidecar/SidecarInterface.
Unable to find common super type for androidx/window/layout/SafeWindowLayoutComponentProvider and androidx/window/extensions/layout/WindowLayoutComponent.
Unable to find common super type for androidx/window/extensions/layout/WindowLayoutComponent and java/lang/Object.

After checking SidecarDeviceState and SidecarInterface there's indeed no common super class for those two.

Isn't it a valid use-case and no warning should be printed in this case?

am...@google.com <am...@google.com> #6May 31, 2022 01:25PM

The common super type should be Object if the classes were loaded correctly, I assume that in that case the androidx library is not on the classpath. I can take a look into this to double check. So to reproduce you are using a plugin that registers an asm visitor to instrument the now-in-android app? with no modification to the app code?

ro...@sentry.io <ro...@sentry.io> #7Jun 13, 2022 10:09AM

Ok, I dug a little bit more into this - turns out the cause is the ClassRemapper from asm-commons. I've put up a reproducer for you here. Just run:

./gradlew app:assembleDebug --console=plain

And you should see the warnings from above.

Without the ClassRemapper (e.g. just a simple ClassVisitor instead) I wasn't seeing those warnings.

I'm not sure whether the issue is on the ASM or AGP's site. I also noticed (as you mentioned), that androidx.window actually defines those libs as compileOnly, and they should be provided by OEM at runtime on target devices, so now-in-android indeed does not contain those dependencies in the tree.

Message last modified on Jun 13, 2022 10:13AM

ro...@sentry.io <ro...@sentry.io> #8Jun 27, 2022 11:24AM

Sorry for pinging you, but have you had a chance to look into this? Thanks

am...@google.com <am...@google.com> #9Sep 29, 2022 12:41PM

Marked as fixed.

Hi, sorry for taking so long to look into this. I've merged a change to better handle instrumentation issues reporting. Now there should be only one warning per class, capped at maximum 10 classes. This what shows for the now-in-android app with your reproducer

ASM Instrumentation process wasn't able to resolve some classes, this means that
the instrumented classes might contain corrupt stack frames. Make sure the
dependencies that contain these classes are on the runtime or the provided
classpath. Otherwise, the jvm might fail to load the corrupt classes at runtime
when running in a jvm environment like unit tests.

Classes that weren't resolved:
> androidx.window.sidecar.SidecarDeviceState
> androidx.window.sidecar.SidecarInterface
> androidx.window.extensions.layout.WindowLayoutComponent

The change should land in AGP 8.0 alpha-04.

ro...@sentry.io <ro...@sentry.io> #10Sep 29, 2022 01:01PM

Thanks a lot, this looks way more informative and nicer!

By any chance, could you take a look at this issue as well, since anyway it's meant to be for you? It gets moved to a wrong issue tracker, even though it should end up in the AGP's one ><.

ke...@gmail.com <ke...@gmail.com> #11Jun 19, 2023 10:30AM

I have faced this issue too, and fixed just by adding missing rules from {your_build}/output/missing_rules.txt file into proper proguard_rules.pro file. You can find this type of error message and path to missing_rules.txt file in build logs. For example, in my case, there were missing.

-dontwarn com.google.android.material.R$id
-dontwarn org.bouncycastle.jsse.BCSSLParameters
-dontwarn org.bouncycastle.jsse.BCSSLSocket
-dontwarn org.bouncycastle.jsse.provider.BouncyCastleJsseProvider
-dontwarn org.conscrypt.Conscrypt$Version
-dontwarn org.conscrypt.Conscrypt
-dontwarn org.conscrypt.ConscryptHostnameVerifier
-dontwarn org.openjsse.javax.net.ssl.SSLParameters
-dontwarn org.openjsse.javax.net.ssl.SSLSocket
-dontwarn org.openjsse.net.ssl.OpenJSSE