- There are 2 methods to deodex a ROM (set of system files whether it be stock or custom). One is doing it manually by using baksmali.jar and smali.jar. The other is easiest but, often not the most reliable. It involves using a script to perform the commands repeatedly. It saves times but there are often several apks or jars that need something different done to them.
- 1. Download baksmali.jar and smali.jar from here: http://code.google.com/p/smali/
Linux users can also grab the wrapper scripts to save yourself some extra typing later
- 2. I personally renamed baksmali-x.x.x.jar to just baksmali.jar and did the same for smali. Its up to you.
Linux users place all 4 files somewhere that is already in your PATH (EX: /usr/local/bin/) or add the folder that they are in to your PATH (path=$PATH:
). Make the files executable (chmod a+x)
Windows users: Create a new folder in you C:\ drive named something like Deodexing. Then place the baksmali.jar and smali.jar in that folder. You can also add that folder to your PATH but I am not 100% sure how to do that as I do not use windows. :Also, create a deodexed app and deodexed jar folder inside of the Deodexing folder to put the files once you complete them.
- 3. Grab your system dump and copy everything from the 'app' and 'framework' folder (*.apk, *.jar, *.odex) into your working folder :(Windows: C:\Deodexing).
- 4. Open up a terminal or command prompt and cd into your working folder (Windows:
- 5. Start by deodexing the .jars to make things easier in the future. Use the command:
java -jar baksmali.jar -x :nameofjar.odex (EX: java -jar baksmali.jar -x android.policy.odex).
- If everything went successful it should return you back to the prompt and create a folder named 'out' inside of your working directory. If it :returned an error it more than likely needs you to specify a custom boot class path, we will cover that later.
(Linux users: if you grabbed the wrapper scripts you can just type 'baksmali' instead of 'java -jar baksmali.jar')
- 6. Once you have the 'out' folder use the command:
java -jar smali.jar out
- This will recompile the out folder into .dex format. You should see a out.dex. Rename that out.dex to classes.dex. Open, not extract, the jar :as an archive using 7zip or something similar and place the classes.dex inside of the archive.
- 7. Clean up by deleting the 'out' folder, classes.dex (after you put it in the archive), and the .odex that you just decompiled.
- 8. Continue to do the same for all the .jar's odex files until you finish. Then move to the apk's odex files. It will be the same process.
- 9. If and when you run into errors it will more than likely look something like this:
Error occured while loading boot class path files. Aborting. org.jf.dexlib.Code.Analysis.ClassPath$ClassNotFoundException: Could not find superclass Ljavax/obex/ServerRequestHandler; at org.jf.dexlib.Code.Analysis.ClassPath$ClassDef.loadSuperclass(ClassPath.java:784) at org.jf.dexlib.Code.Analysis.ClassPath$ClassDef.
(ClassPath.java:668) at org.jf.dexlib.Code.Analysis.ClassPath.loadClassDef(ClassPath.java:280) at org.jf.dexlib.Code.Analysis.ClassPath.initClassPath(ClassPath.java:163) at org.jf.dexlib.Code.Analysis.ClassPath.InitializeClassPathFromOdex(ClassPath.java:110) at org.jf.baksmali.baksmali.disassembleDexFile(baksmali.java:98) at org.jf.baksmali.main.main(main.java:278) Error while loading class Lcom/android/bluetooth/opp/BluetoothOppObexServerSession; from file BluetoothOPP.odex Error while loading ClassPath class Lcom/android/bluetooth/opp/BluetoothOppObexServerSession;
- When this happens you have to specify the boot class path. It usually give you some sort of clue as what to add. In this example I attempted to deodex BluetoothOPP.odex. The line that says "Could not find superclass Ljavax/obex/...." is you clue. If you look in the folder there should be a .jar with a name that is similar to that clue. In this example I found javax.obex.jar. We need to add this as a path to be included in the deodexing. To do this use the following command:
java -jar baksmali.jar -c :javax.obex.jar -x BluetoothOPP.odex
- Note the colon (:) is important. It stands for the default class paths (core.jar|ext.jar|framework.jar|android.policy.jar|services.jar), without it you have to type each one plus the custom one.
EX: java -jar baksmali.jar -c core.jar:ext.jar:framework.jar:android.policy.jar:services.jar:javax.obex.jar -x BluetoothOPP.odex
- It is very possible that you will have more than one custom custom boot class path. Use a colon (:) to separate them, like the example above.
- 10. In theory you should have all apks and jars deodexed. Separated them by placing all apks inside the deodexed app folder and all the jars inside of the deodexed jar folder (excluding the framework-res.apk it should be in deodexed jar). Package them up in a flashable theme .zip and flash. It is usually best to use a previously made ZIP to reduce the amount of errors. I have :included a blank zip here that includes an update-script and deodex.sh, which deletes the now unneeded .odex files from the phone.
- Download it HERE
- We started by deodexing the jars because once you start doing the apks you will have some that you need to specify the boot class paths. You can specify either the .jar or the .odex and to keep it all uniform it is best to use just one or the other. If you decide to do the apks first your command for custom boot class paths would be something like this:
java -jar baksmali.jar -c :javax.obex.odex:com.google.maps.odex -x APK.odex
You can also use the -o option with both baksmali and smali to specify the output.
EX: java -jar baksmali.jar -c :javax.obex.jar -x BluetoothOPP.odex -o bluetooth --this will name the output folder 'bluetooth' EX: java -jar smali.jar bluetooth -o classes.dex --this will recompile it into a classes.dex
- 1. They work basically the same way. Follow the instructions from the location that has the script.
- 2. Most scripts will not deodex the entire rom due to the custom boot class paths. Typically they will leave the left over apks in a folder and you can just manually do the remainder. Then package it up same as above
- Several apks may have sound files inside of them, phone.apk for example, and most scripts compress the apks after they finish deodexing. If an apk has a sound file and is compressed, it will not function properly. This is the main reason it is more stable to deodex the ROM manually. Usually you will know when an apk has sound files when the particular apk continues to FC (force close).
Notable Links.'via Blog this'