Decompiling Dalvik to Java, why are there so many inconsistencies?
I used dex2jar and JD-gui on the dex file of an application, although in several parts of the code it didn’t make sense and had errors in decompiling.
While the code is correct when I use backsmali on dex files, I prefer to read Java code rather than Smali to understand how a large application works.
First of all, why are there so many inconsistencies in Java code? Is this a problem with dex2jar or JD-gui? Are there other options?
Solution
Even from .class files to .java files, decompilation is usually not perfect.
One is the simple fact that compilation does not represent all the information of the source files in the .class file. Spaces and comments are the most obvious examples of information that are not represented in .class files. Local variable names are also often omitted, and depending on your compilation flags, even parameter names can be missing.
On the other hand, the market for decompilers seems to be quite limited, and the lack of competition prevents decompilers from working as they are possible. For example, each new version of the Java compiler may generate new code that requires an equivalent update to the decompiler to detect new patterns and generate appropriate Java source code from them. Without such an update, the decompiler is bound to either fail and print bytecode disassembly, or produce strange-looking structures that do the same thing but will never be written by a person.
When you add another compilation level (Java bytecode -> Dalvik bytecode), it only gets worse.
Unless you can give a
concrete example of what you mean, it’s hard to give a better answer.