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?


1 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.

  • +1 - it would be interesting to see a specific example so we can try to figure out what's going on, and maybe work around it. May 11, 2016 at 6:33
  • OK I've uploaded the jar file to the following dropbox link - dl.dropboxusercontent.com/u/18288498/UniversalMDMClient.jar. There are many classes that exhibit the multiple file behavior, but specifically, look at the following: Under com.sec.enterprise.knox.cloudmdm.smdms.core, Core, g and h seem to be the same class. BulkEnrollmentManager, c, d, e and f seem to be the same class. Under com.sec.enterprise.knox.cloudmdm.smdms.agent, a and b seem to be the same class. May 12, 2016 at 6:58
  • @user1118764 I'll take a look this weekend
    – Antimony
    May 12, 2016 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.