Decompiled Java classes span multiple files

Question

I've been playing around with decompiling Android apps from dex/jar files to java source code, with varying success. I've tried the usual suspects - JD-GUI, procyon, cfr, krakatau and jadx. I'm having a specific problem with all of them on a particular app in that it's obfuscated, and many classes seem to be split up into multiple files. AFAIK, this isn't allowed in Java.

Also, the classes seem to extends multiple base classes, e.g. class a extends Activity, and class a(or renamed to something else but I know is actually class a as it tries to access a's private member variables directly) extends BroadcastReceiver. AFAIK, this isn't allowed in Java either.

As a result, the decompiled code is full of errors and hard to follow. I'm not expecting a compileable code form the decompiled code, but I do wish to at least be able to perform meaningful static analysis, which is hard to do when the decompiled source doesn't follow java conventions.

Any help on how to resolve this decompilation issue?

Thanks.

Answer 1

It is impossible for Krakatau to generate java files like that, and I imagine the same is true for other decompilers. However, I can think of some things that might lead to your confusion.

First off, nested and inner classes in Java are considered independent classes and are compiled into seperate classfiles. This is true even for anonymous classes, such as every time you use the double brace initialization pattern. Depending on the decompiler and settings, the classes might be decompiled independently or merged back into one file. This is the only thing I can think of which could be described as a class "split up into multiple files".

As for a class extending multiple superclasses, this is obviously also impossible (though an interface can extend multiple superinterfaces). Most likely what happened is that you are confusing a class and its nested classes.

For example, you could have the main class A which subclasses Activity. Then A has an nested class, say A$1, which subclasses BroadcastReceiver. As a nested class, A$1 will of course have access to A's private members. (Note that this is technically not true at the bytecode level. The private members are accessed indirectly by compiler generated wrappers, which may or may not be shown, depending on the decompiler you use).

Alternatively, you may be mixing up unrelated classes with the similar names, such as A and a.

P.S. Krakatau is one of the decompilers that explicitly shows compiler generated accessors, so you definitely shouldn't be seeing direct access to private members of other classes. If you provide the app you are analyzing and the classes in question, I can try to figure out what's going on.