When decompiling an apk with apktool, the classes.dex file is decompiled into folders smali_classes#, and sorted their respective packages. I recognize some of the files, as they are mentioned in AndroidManifest.xml, but some classes and packages are named with one or two letters (Like aa, az, b, etc.).

I don't think that this is obfuscation, because if someone was to obfuscate the code, they would probably apply it to every class.

Are these strangely named classes just some sort of reference made by the Android compiler, or could it indeed be obfuscated code? They don't seem to be references, as some of the single letter files are generally not too short.

1 Answer 1


I'd still say these are obfuscated classes, probably not written by the author of the apk himself, but some 3rd-party library.

The provider of the 3rd-party library wants to protect their own implementation, so they provide a few unobfuscated class/method names to the world, and obfuscate their internal code. When someone else builds an apk, they'll include that library in their .dex file, so even if the app programmer doesn't obfuscate their classes, the classes that come from the 3rd party library are still obfuscated.

For example, this is the listing of the files that Oracle's oraclepki.jar contains (not that I assume your app uses an oracle database, but that's an example I had handy):

$ unzip -l oraclepki.jar
Archive:  oraclepki.jar
  Length      Date    Time    Name
---------  ---------- -----   ----
      233  2012-12-06 00:33   META-INF/MANIFEST.MF
     2272  2012-12-06 00:33   a.class
     8479  2012-12-06 00:33   KeyStoreTest.class
      242  2012-12-06 00:33   oracle/security/pki/BadPaddingException.class
     6160  2012-12-06 00:33   oracle/security/pki/a.class
     5575  2012-12-06 00:33   oracle/security/pki/b.class
      717  2012-12-06 00:33   oracle/security/pki/c.class
     5561  2012-12-06 00:33   oracle/security/pki/Cipher.class
     1360  2012-12-06 00:33   oracle/security/pki/CipherSpi.class
     9102  2012-12-06 00:33   oracle/security/pki/d.class
      926  2012-12-06 00:33   oracle/security/pki/DESSecretKey.class
     2395  2012-12-06 00:33   oracle/security/pki/e.class
      827  2012-12-06 00:33   oracle/security/pki/DESedeSecretKey.class
     2663  2012-12-06 00:33   oracle/security/pki/FileLocker.class
      248  2012-12-06 00:33   oracle/security/pki/IllegalBlockSizeException.class
      495  2012-12-06 00:33   oracle/security/pki/IvParameterSpec.class
     1367  2012-12-06 00:33   oracle/security/pki/NZNative.class
      245  2012-12-06 00:33   oracle/security/pki/NoSuchPaddingException.class
     5529  2012-12-06 00:33   oracle/security/pki/OracleCRL.class
     1094  2012-12-06 00:33   oracle/security/pki/OracleCertExtension.class
     2385  2012-12-06 00:33   oracle/security/pki/f.class
     9041  2012-12-06 00:33   oracle/security/pki/g.class
      592  2012-12-06 00:33   oracle/security/pki/h.class
     6513  2012-12-06 00:33   oracle/security/pki/i.class
     1212  2012-12-06 00:33   oracle/security/pki/j.class
      634  2012-12-06 00:33   oracle/security/pki/k.class

Classes like Cipher, NZNative etc. are supposed to be callable from the outside, but Oracle doesn't want you to know what a.class, b.class etc. are doing.

If someone built an app that somehow connects to an oracle database using the wallet feature, they'd have to include these classes into the app's classes.dex, so this is what you'd see in apktool as well.

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.