apkanalyzer与dex2jar输出差异原因及结果正确性验证

Let’s unpack this discrepancy—this is a common gotcha with obfuscation testing, and the root cause boils down to how each tool interacts with your APK.

First, let’s clarify what each tool actually does #

• apkanalyzer: This is Google’s official SDK tool that reads directly from your APK’s raw DEX files. No decompilation, no conversion—it just parses the class names exactly as they exist in the bytecode that would run on a user’s device. If it says obfuscation is working as expected, that’s the real state of your APK.
• dex2jar + JD-Gui: dex2jar converts DEX files to standard Java JARs, and JD-Gui decompiles that JAR back to readable code. The problem here is that this two-step process can introduce errors or pull in unexpected data from your APK that overrides obfuscated names.

Why you’re seeing different results #

Here are the most likely culprits for the mismatch:

1. dex2jar is picking up unobfuscated metadata from your APK: Your app might include extra files (like debug symbols, R.txt, or even leftover unobfuscated resources) that dex2jar incorrectly interprets as the "real" class names. Unlike apkanalyzer, which focuses solely on the DEX content, dex2jar sometimes merges data from other parts of the APK that haven’t been obfuscated.
2. Outdated dex2jar version: If you’re using an older build of dex2jar, it might not handle modern Android obfuscation (especially from R8, Google’s replacement for ProGuard) correctly. Newer DEX formats or obfuscation techniques can throw off older conversion tools, leading them to fall back to original class names from the APK’s string pool or other sources.
3. Accidental deobfuscation in JD-Gui: Though rare, some decompilers (or their plugins) automatically apply mapping.txt files if they’re in the same directory. If JD-Gui is using your mapping.txt to "undo" obfuscation, that would explain why you see original class names—even though the DEX itself is obfuscated.

Which tool can you trust? #

apkanalyzer is the definitive source here. It’s built and maintained by the Android team to inspect APKs accurately, with no intermediate steps that could skew results. If it shows your classes are obfuscated, that’s exactly what’s in the APK you’d ship to users.

The dex2jar/JD-Gui combo is giving you misleading output—your Demo project working fine confirms this is specific to your app’s build setup or how dex2jar interacts with your APK’s structure.

Steps to fix the confusion and verify #

• Upgrade dex2jar to the latest version: Newer builds handle modern DEX and R8 obfuscation much better.
• Use jadx instead: Jadx is a more reliable decompiler for Android apps that reads DEX files directly (no conversion to JAR first). It’ll show you the actual obfuscated class names without the quirks of dex2jar.
• Inspect your APK manually: Unzip your APK with unzip myapp.apk, then check the classes.dex file directly with a DEX viewer. This will eliminate any tool-related variables.
• Double-check your build configuration: Ensure your release variant has minifyEnabled true set in your build.gradle/build.gradle.kts, and that your ProGuard/R8 rules aren’t accidentally preserving class names (though apkanalyzer’s results suggest this isn’t the case here).

内容的提问来源于stack exchange，提问作者Omer Levi Hevroni