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
/system/priv-app/my_app/my_app.apk
/system/priv-app/my_app/my_app.apk!classes2.dex
/system/priv-app/my_app/my_app.apk!classes3.dex
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.