Sometimes when trying to decompile an Android APK it will appear almost empty, containly mostly resources and very little code. This is a “feature” of the Android operating system: optimizing the app by “pre-compiling” the code, the classes.dex file is removed from the APK and you should have the following file structure, or something similar depending on your platform:

|-- oat
|   `-- arm
|       |-- my_app.odex
|       `-- my_app.vdex
`-- my_app.apk

The APK file is esentially useless (unless you’re interested in the app’s resources), and the .vdex file won’t be of much use either.

A handly little tool will help you for the next steps: smali/baksmali by JesusFreke.

Start off by listing the DEX files contained in the .odex:

$ baksmali list dex my_app.odex

In this example, the .odex file contains 3 classes.dex files that you will need to deodex individually

You can also list the classes contained in each classes.dex to see if you can avoid deodexing certain files:

$ baksmali list classes my_app.odex
$ baksmali list classes my_app.odex/classes2.dex
$ baksmali list classes my_app.odex/classes3.dex

If you’re decompiling a system app, you may require some system framework components (path depends on device platform):

$ cp /system/framework/arm/*.oat .
$ cp /system/framework/arm/*.vdex .

Now for the actual deodexing, providing boot.oat and using /tmp/my_app as the output folder:

$ baksmali deodex -b boot.oat -o /tmp/my_app my_app.odex
$ baksmali deodex -b boot.oat -o /tmp/my_app my_app.odex/classes2.dex
$ baksmali deodex -b boot.oat -o /tmp/my_app my_app.odex/classes3.dex

In your output folder you should now have plenty of folders, subfolders and .smali files that you can view as Java with jadx-gui.