[feature] Use Kotlin's internal null checks to get variable names

[ReimarPB]

When Kotlin code is compiled, a bunch of null checks will be added to the code. Some of these may include the variable names from the original source code to generate more helpful error messages.

Here is an example snippet from an APK I recently decompiled using JADX GUI:

public SpannableStringBuilder mo29878b(SpannableStringBuilder spannableStringBuilder, TextSupplyData gj7) {
        Intrinsics.checkNotNullParameter(spannableStringBuilder, "builder");
        Intrinsics.checkNotNullParameter(gj7, "data");
        List<Mention> b = ek7.getMentions(spannableStringBuilder, true);
        Intrinsics.checkNotNullExpressionValue(b, "mentions");

Notice how it uses these internal methods to check if the parameters and variables are null. The first parameter is the actual value, while the second parameter is a string representation of it. The Intrinsics module is imported from kotlin.jvm.internal.Intrinsics and the source code for that can be found here.

These are the list of methods I found to be useful for decompilation:

• checkExpressionValueIsNotNull(Object value, String expression)
• checkNotNullExpressionValue(Object value, String expression)
• checkReturnedValueIsNotNull(Object value, String className, String methodName)
• checkFieldIsNotNull(Object value, String className, String fieldName)
• checkParameterIsNotNull(Object value, String paramName)
• checkNotNullParameter(Object value, String paramName)

My suggestion is that during decompilation, JADX should check to see if these methods are being called and if they are, change the variable, parameter, method and class names according to the strings provided in the second (and third) parameter.

[jackwpa]

Not the best idea to trust metadata blindly. It can easily be modified by code protectors. Same goes for dex debug metadata. All those items should be imported as opt-ins only imo (default being no import). That's how JEB does it afair.

[sladen]

This is a genius idea; and in 98%+ of the cases should be 100% correct. Such an easy and simple win!

[skylot]

Implemented 🎉
Check Use kotlin methods for variables rename preference in jadx-gui or --use-kotlin-methods-for-var-names in jadx-cli

Additional implementation details:

• supported renamed Intrinsics class if package not changed
• methods names not hard coded because Intrinsics class often changing between Kotlin versions
• feature to hide these methods call after successful variable rename (for better code readability)

Any suggestions and samples are welcome 👍

[ed9w2in6]

Sorry if this is not the right place for such questions.

I have been trying this feature but I see that in some apps the Intrinsics class is located somewhere else.
From jadx's comments it shows the class is inferred from a class named a.b.c with c being detected as Intrinsics. As it is one level shorter than kotlin.jvm.internal.Intrinsics I cannot fix this manually by renaming.

May I ask if there are any existing method that can allow me to do so?

[ed9w2in6]

Edited:
A method to manually rename class to different packages is described in #1590.
Not sure why it didn't show up before when I searched for it.
May I ask if I rename them and I click reload this automatic variable name inference will be run?