[HOW TO][Windows] Manually Deodex and Odex back

Search This thread

sicopat

Senior Member
Oct 21, 2007
811
957
Samsung Galaxy S20
The purpose of this thread is to give basics to manually deodex and odexing back framework and apk files

Credits and Thanks to :
jubeh
Decad3nce
software_samurai
JKay
LeoMar75

and many others I forgot


Theory :
WHAT IS AN ODEX FILE?

In Android file system, applications and framework files come in packages with the extension .apk or .jar. These APKs or JARs contain certain .odex files whose supposed function is to save space. These ‘odex’ files are actually collections of parts of an application that are optimized before booting. Doing so speeds up the boot process, as it preloads part of an application. On the other hand, it also makes hacking those applications difficult because a part of the coding has already been extracted to another location before execution.

THEN COMES DEODEX

Deodexing is basically repackaging of these APKs or JARs in a certain way, such that the .odex files are reassembled into classes.dex files directly integrated inside the APKs or JARs. By doing that, all pieces of an application package are put together back in one place.
For now, we need Baksmali.jar and Smali.jar to deodex, it seems these tools are not perfect and it seems to be why deodexed stock browser is laging/freezing.
This is the reason why there is a return to odexed customROMs


Prerequisites :

You will need these files :
* backsmali.jar
* smali.jar
* custom java.awt.jar
* dexopt wrapper
* recent version of busybox
all included in the attached .zip (end of post)

You will also need :
* your GS2
* with the official odexed firmware you want to mod
* rooted and with root explorer (pay app but really usefull) and with CWM recovery (better :))
* ADB installed and working in su (#)
* copy dexopt-wrapper in /system/bin/ and giving it 755 permissions (using root explorer or command: chmod 755 /system/bin/dexopt-wrapper
* optional (if errors during odexing back) overwrite installed busybox with the one included here in /system/xbin/

You have to know :
* even on stock firmware (odexed) there are some deodexed .apk (like framework-res.apk in /system/framework/ and like some .apk in system/app/)

Tip on Windows "Vista / 7" : open a CMD prompt in a specified folder
1. Select the folder you want to open in the command prompt
2. Right-click on it while holding the Shift key
3. Select Open command window here



Manually Deodexing :

theory :
to decompil an odex file you need Baksmali.jar and you needs the BOOTCLASSPATH
BOOTCLASSPATH is a list in specific order of some framework .jar files

** To decompil and re-odex back .odex from JAR file you need to use the BOOTCLASSPATH specified in the init.rc file located in the root folder of your GS2 : (open init.rc with notepad ++)

Extract of I9100 init.rc :
export BOOTCLASSPATH /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar

** To decompil an .odex from APK file, BOOTCLASSPATH is different in fonction of the APKs, so the lazy way is to include all the .JAR files of the framework folder
2 applications : Emails.apk and MobilePrint.apk needs one more custom java.awt.jar


1/ put in the same folder :
* apk to deodex
* all system/framework files
add :
* custom java.awt.jar
* baksami.jar
* smali.jar
* zipalign.exe

2/ open CMD prompt in this folder (see above for how to)

3/ Deodexing Framework file (I will take android.policy.jar for example) :

* BAKSMALI of the android.policy.odex :
Code:
java -Xmx1024m -jar baksmali.jar -c :core.jar:bouncycastle.jar:ext.jar:framework.jar:android.policy.jar:services.jar:core-junit.jar -x [B]android.policy.odex[/B]

* This create an out folder. You can now modify some files (like adding Advanced power menu)

* SMALI the /out folder in a classes.dex file :
Code:
java -Xmx1024m -jar smali.jar [B]out[/B] -o classes.dex

* finally deodex your android.policy.jar :
open android.policy.jar with 7zip without extracting
push the classes.dex created in the 7zip window in the root folder
close the 7zip windows and here is your deodexed android.policy.jar :)


4/ Deodexing APK in system/app (I will take SystemUI.apk for exemple) :

* BAKSMALI of the SystemUI.odex :
Code:
java -Xmx1024m -jar baksmali.jar -c :am.jar:android.policy.jar:android.test.runner.jar:bmgr.jar:bouncycastle.jar:com.android.location.provider.jar:com.google.android.maps.jar:com.samsung.device.jar:com.yamaha.android.media.jar:core.jar:core-junit.jar:ext.jar:framework.jar:ime.jar:input.jar:[B]java.awt.jar[/B]:javax.obex.jar:libvtmanagerjar.jar:monkey.jar:pm.jar:sec_feature.jar:seccamera.jar:sechardware.jar:secmediarecorder.jar:services.jar:sqlite-jdbc.jar:svc.jar:twframework.jar -x [B]SystemUI.odex[/B]

* an out folder is created. You can modify the files inside if you want.

* SMALI the /out folder in a classes.dex file :
Code:
java -Xmx1024m -jar smali.jar [B]out[/B] -o classes.dex

* finally deodex your SystemUI.apk :
open SystemUI.apk with 7zip without extracting
push the classes.dex created in the 7zip window in the root folder
close the 7zip windows and here is your deodexed SystemUI.apk :)

* extra step for APKs : zipaplign of your new deodexed SystemUI.apk
--> In the same CMD prompt windows, type :
Code:
zipalign -v 4 SystemUI.apk zip_SystemUI.apk
A zip_SystemUI.apk file is created. Delete your deodexed SystemUI.apk and rename zip_SystemUI.apk in SystemUI.apk



ODEXING BACK :

the theory :
*You will need to copy the (custom) deodexed file (.jar or .apk) in the system/framework/ folder of your phone.
*You will use dexopt wrapper (already copied in your phone) to obtain a new .odex file (patched_android.policy.odex for example)
* You will copy the signature of original .odex file to patched.odex file - if not, the phone won't boot ...

How To :
1/ backup your original files (apk jar and odex) to /sdcard/Mod/
2/ copy modified deodexed files (.apk and .jar) in /system/framework/ of your GS2

Now we are going to odex back :)

3/ open a CMD prompt in the folder of adb.exe (usualy /android-sdk-windows/platform-tools/)
4/ type command :
Code:
adb shell
su
## for .JAR file :
dexopt-wrapper /system/framework/XXX.jar /system/framework/patched_XXX.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar

response must be :
--- BEGIN '/system/framework/android.policy.jar' (bootstrap=0) ---
--- waiting for verify+opt, pid=7194
--- would reduce privs here
--- END '/system/framework/android.policy.jar' (success) ---

## for .APK file :
dexopt-wrapper /system/framework/XXX.apk /system/framework/patched_XXX.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
--> This will create the patched_XXX.odex file

Now we need to copy signature from original .odex file to patched .odex file cause Dalvik need files signature integrity in order to boot.

5/ always in the same CMD prompt windows :
Code:
# if not already done ...
adb shell
su

# copy the original .odex and .jar in system/framework (not .apk) : 
cp /sdcard/MOD/original.XXX.odex /system/framework
cp -f /sdcard/MOD/XXX.jar /system/framework   # where XXX.jar is the original odexed .jar

# give all permissions to XXX.odex files :
chmod 777 /system/framework/original.XXX.odex
chmod 777 /system/framework/patched_XXX.odex

# copy signature :
busybox dd if=/system/framework/original.XXX.odex of=/system/framework/patched_XXX.odex bs=1 count=20 skip=52 seek=52 conv=notrunc

response must be :
busybox dd if=/system/framework/original.XXX.odex of=/system/framewor
k/patched_XXX.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
20+0 records in
20+0 records out
20 bytes (20B) copied, 0.002042 seconds, 9.6KB/s

Now the signature is copied over the patched_XXX.odex

Notice :
a - if you don't have response after busybox dd command : busybox is not installed or you have a to old version, use the busybox included in the attached .zip
b - if you don't have the last response line : 20 byt
 

Attachments

  • all_for_deodexing_reodexing.zip
    5.4 MB · Views: 25,138
Last edited:

Mekrel

Senior Member
Apr 20, 2010
374
136
Buckinghamshire
Thanks for the guide, just a quick question.

Can I odex a custom deodexed ROM? Just that will save me time.

If not, I'll unpack an official ROM and made my mods. You've posted some other great guides which has really helped me tonight! Thanks again.
 

sicopat

Senior Member
Oct 21, 2007
811
957
Samsung Galaxy S20
Thanks for the guide, just a quick question.

Can I odex a custom deodexed ROM? Just that will save me time.

If not, I'll unpack an official ROM and made my mods. You've posted some other great guides which has really helped me tonight! Thanks again.

Yes you can odex back a customROM (in theory) I never try to, but you will need to odex back all the .jar of the framework folder. And you will need the original firmware to copy signature of original .odex files to re-odexed .odex files

Sent from my GT-I9100 using XDA Premium App
 

sicopat

Senior Member
Oct 21, 2007
811
957
Samsung Galaxy S20
nice tutorial :)
I've successfully deodex them.
lets try odex them back .

Sometimes it will work the first time.
Sometimes it won't cause you forgot to give good permissions to dexopt-wrapper in system/bin
Or to the pached_XXX.odex files (need write permissions for all)

Or Busybox not installed or to old... Then the copy signature step won't work

Sent from my GT-I9100 using XDA Premium App
 
Last edited:
  • Like
Reactions: pjc21
Great ! I was looking for this, thank you.

One thing was still giving me a hard time and i got that one solved also.
When doing a odex back from a custom theme, the method is different.

Because you need to use the modified framework file in the dependencylist.
So for me it was:

(I put a modified framework.jar in /sdcard)


dexopt-wrapper /sdcard/framework.jar /sdcard/framework.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/sdcard/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar


Otherwise it does NOT work. Now i have succusfully added overglow to a odex ROM. :D
 
Last edited:
Ok a new problem with the framework.jar

In the method to odex on the FP there was mentioned to use the dependency framework stuff.

When doing that trying to odex framework.jar i only get bootloops. aka the created odex file is wrong. The weird part is that the odex file created is 6,8 mb

When using the method i proposed in including the modified framework.jar in the dependencylist a bigger framework.odex is created. This one is about 7,14 mb
And it boots !

But it seems to be messed up because when trying to do some settings i get fc or it just exits. It appears to focus on phone settings. (try adding a apn and it closes)

Does anyone know of a solution for this ?
I did try to add the java.awt.jat in the dependencylist, but it does not seem to matter at all.
 
  • Like
Reactions: ohaleck

sicopat

Senior Member
Oct 21, 2007
811
957
Samsung Galaxy S20
Yes you need to use your modded framework.jar in bootclasspath dependencies of dexopt wrapper.

If force close, perhaps you did not erase dalvik cache or made a mistake when modding framework.jar
Did you use the last Smali version out today x.7 to make your mod ? cause smali.jar was buggy with framwork.jar deodexing.

If you just want to odex a theme with more than 1 framework file, you should need to do by step : first you copy 1 file and odex it back then you do the same for second file ... You should only use 1 deodexed jar in your bootclasspath corresponding to the file you try to odex back.

Hope this will help, i cannot help much cause my GS2 doesn't really love the beautifull sand of the mediteraneen sea :) I am on vacation ...


Sent from my GT-I9100 using XDA Premium App
 
Last edited:
Thanx for the reply, i did just that.

The framework.jar file works flawlessly on a deodexed system, so i guess this file is ok.

But it does not work correctly when trying to odex back. I keep getting (thesame ) errors. Even doing a binary compare of the odex files when trying different methods to odex back is identical.

But the endresult is always thesame. The phone does boot but there are issues inside the jarfile.
 

sicopat

Senior Member
Oct 21, 2007
811
957
Samsung Galaxy S20
Thanx for the reply, i did just that.

The framework.jar file works flawlessly on a deodexed system, so i guess this file is ok.

But it does not work correctly when trying to odex back. I keep getting (thesame ) errors. Even doing a binary compare of the odex files when trying different methods to odex back is identical.

But the endresult is always thesame. The phone does boot but there are issues inside the jarfile.

I just remember that original developper of overscroll glow for Galaxy S has stopped to dev odexed owerscroll glow cause of same errors (MMS)
I believe this due to a dexopt wrapper bug on odexing back framework.odex ??
 

Mekrel

Senior Member
Apr 20, 2010
374
136
Buckinghamshire
Hi Sicopat,

I'm having issues with this.

I'm currently running XXKG6 ROM that I've successfully deodexed and after reading your thread, I've wrote the below shell script that successfully runs.

Code:
#!/system/bin/sh

chmod 755 /system/bin/dexopt-wrapper
chmod 755 /system/bin/zip

coreframework="/system/framework/core.jar /system/framework/bouncycastle.jar /system/framework/ext.jar /system/framework/framework.jar /system/framework/android.policy.jar /system/framework/services.jar /system/framework/core-junit.jar"

echo "Odexing /system/framework/*jar files"

for i in $coreframework
do	
	filename=$(basename $i .jar)
	dexopt-wrapper $i /system/framework/$filename.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
	zip -d $i classes.dex
done


for i in /system/framework/*.jar
do
	if [ $i == "/system/framework/core.jar" -o $i == "/system/framework/bouncycastle.jar" -o $i == "/system/framework/ext.jar" -o $i == "/system/framework/framework.jar" -o $i == "/system/framework/android.policy.jar" -o $i == "/system/framework/services.jar" -o $i == "/system/framework/core-junit.jar" ]
		then
			echo "Already odexed in sequence"
		else
			filename=$(basename $i .jar)
			dexopt-wrapper $i /system/framework/$filename.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
			zip -d $i classes.dex	
	fi
done

echo "Giving permissions to all *odex files"
chmod -R 777 /sdcard/original-framework/*.odex
chmod -R 777 /system/framework/*.odex

echo "Copying signatures from original odex files"
for i in /sdcard/original-framework/*.odex
do
	filename=$(basename $i .odex)
	busybox dd if=$i of=/system/framework/$filename.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
done

rm -r /data/dalvik-cache/*

The script does the following process:
  1. Sets permisions for the dexopt-wrapper and zip binaries.
  2. Odexes the core framework in the same order they're listed in BOOTCLASSPATH in init.rc.
  3. Odexes the other framework files that were not previously odexed
  4. Copies the signatures from the original XXKG6 .odex files, to the ones that have just been created (the origials are stored on the sdcard)

The only difference in the script I wrote is the classes.dex are removed from the .jar files using the zip binary.

I can see the .odex files created when running a ls /system/framework command and pulling the .jar files reveals that the dex file from inside has been removed.

I've also tried copying the original .jar files over, rather than removing the .dex files on the fly.

However, the phone doesn't even boot, i.e. it doesn't even get past the splash image.

Can you see anything wrong with my logic/shell script? :confused:

Many thanks
Mark
 

Mekrel

Senior Member
Apr 20, 2010
374
136
Buckinghamshire
Hi Sicopat,

I'm having issues with this.

I'm currently running XXKG6 ROM that I've successfully deodexed and after reading your thread, I've wrote the below shell script that successfully runs.

Code:
#!/system/bin/sh

chmod 755 /system/bin/dexopt-wrapper
chmod 755 /system/bin/zip

coreframework="/system/framework/core.jar /system/framework/bouncycastle.jar /system/framework/ext.jar /system/framework/framework.jar /system/framework/android.policy.jar /system/framework/services.jar /system/framework/core-junit.jar"

echo "Odexing /system/framework/*jar files"

for i in $coreframework
do	
	filename=$(basename $i .jar)
	dexopt-wrapper $i /system/framework/$filename.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
	zip -d $i classes.dex
done


for i in /system/framework/*.jar
do
	if [ $i == "/system/framework/core.jar" -o $i == "/system/framework/bouncycastle.jar" -o $i == "/system/framework/ext.jar" -o $i == "/system/framework/framework.jar" -o $i == "/system/framework/android.policy.jar" -o $i == "/system/framework/services.jar" -o $i == "/system/framework/core-junit.jar" ]
		then
			echo "Already odexed in sequence"
		else
			filename=$(basename $i .jar)
			dexopt-wrapper $i /system/framework/$filename.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
			zip -d $i classes.dex	
	fi
done

echo "Giving permissions to all *odex files"
chmod -R 777 /sdcard/original-framework/*.odex
chmod -R 777 /system/framework/*.odex

echo "Copying signatures from original odex files"
for i in /sdcard/original-framework/*.odex
do
	filename=$(basename $i .odex)
	busybox dd if=$i of=/system/framework/$filename.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
done

rm -r /data/dalvik-cache/*

The script does the following process:
  1. Sets permisions for the dexopt-wrapper and zip binaries.
  2. Odexes the core framework in the same order they're listed in BOOTCLASSPATH in init.rc.
  3. Odexes the other framework files that were not previously odexed
  4. Copies the signatures from the original XXKG6 .odex files, to the ones that have just been created (the origials are stored on the sdcard)

The only difference in the script I wrote is the classes.dex are removed from the .jar files using the zip binary.

I can see the .odex files created when running a ls /system/framework command and pulling the .jar files reveals that the dex file from inside has been removed.

I've also tried copying the original .jar files over, rather than removing the .dex files on the fly.

However, the phone doesn't even boot, i.e. it doesn't even get past the splash image.

Can you see anything wrong with my logic/shell script? :confused:

Many thanks
Mark

Okay, I actually got this to work by removing the copying of signatures from the stock .odex files to the new ones.

I find that a little weird seeing as that step is specifically mentioned in your guide and that the phone is supposedly unable to boot without copying the signature.
 

NitroOnTheRocks

Senior Member
Jun 19, 2008
142
31
After deodexing (and not odexing back) my framework and app folder of my custom ROM in my kitchen (before flashing),
is it necessary to sign/resign apks?
 

Arhtard

Senior Member
Aug 7, 2011
240
73
Salt Lake City
ok i have a few questions if you wouldnt mind helping.
i've been using androids since July of this year, only 2 months now, so i'm really new to modding...
i'm trying very hard to catch on and to learn...
unfortunately, i purchased a device with absolutely no development

anyway, assuming that you'll help, i'll proceed...

i'm not on a galaxy s II - i'm doing this on a gravity smart.

our bootclass path is different:
system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
your bootclass path:
/system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar

so i removed the difference in your command example to this:
java -Xmx1024m -jar baksmali.jar -c :core.jar:framework.jar:android.policy.jar:services.jar -x android.policy.odex

all is fine, i get an "out" folder created with files in it
i then use your command example:
java -Xmx1024m -jar smali.jar out -o classes.dex
and a classes.dex is created
i then opened the android.policy.jar with 7zip and dropped the classes.dex file in its root
i'm assuming the process is going as its supposed to at this point.

question 1: am i doing this right?

question 2: do i do this to all the .jars in the /system/framework/ directory to have a completely deodexed system (and of course all the /system/app/files)?

question 3: do i also use these methods or the apk methods listed on your 2nd post to do the twframework-res.apk file?

question 4: do i create a new "out" folder for each .jar (run the command line for each .jar) or do i use the first created classes.dex for all the .jar files in /system/framework/ directory?

question 5: after i create the deodexed files i can safely delete the .odex companion files correct? (this may be a dumb question with an obvious answer, but i don't want to screw up)

question 6: can i place the deodexed files on the sdcard and move them with root explorer or do i need to push them thru using ADB?

any help or suggestions would be greatly appreciated!
 

sicopat

Senior Member
Oct 21, 2007
811
957
Samsung Galaxy S20
ok i have a few questions if you wouldnt mind helping.
i've been using androids since July of this year, only 2 months now, so i'm really new to modding...
i'm trying very hard to catch on and to learn...
unfortunately, i purchased a device with absolutely no development

anyway, assuming that you'll help, i'll proceed...

i'm not on a galaxy s II - i'm doing this on a gravity smart.

our bootclass path is different:
system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
your bootclass path:
/system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar

so i removed the difference in your command example to this:
java -Xmx1024m -jar baksmali.jar -c :core.jar:framework.jar:android.policy.jar:services.jar -x android.policy.odex

all is fine, i get an "out" folder created with files in it
i then use your command example:
java -Xmx1024m -jar smali.jar out -o classes.dex
and a classes.dex is created
i then opened the android.policy.jar with 7zip and dropped the classes.dex file in its root
i'm assuming the process is going as its supposed to at this point.

question 1: am i doing this right?

question 2: do i do this to all the .jars in the /system/framework/ directory to have a completely deodexed system (and of course all the /system/app/files)?

question 3: do i also use these methods or the apk methods listed on your 2nd post to do the twframework-res.apk file?

question 4: do i create a new "out" folder for each .jar (run the command line for each .jar) or do i use the first created classes.dex for all the .jar files in /system/framework/ directory?

question 5: after i create the deodexed files i can safely delete the .odex companion files correct? (this may be a dumb question with an obvious answer, but i don't want to screw up)

question 6: can i place the deodexed files on the sdcard and move them with root explorer or do i need to push them thru using ADB?

any help or suggestions would be greatly appreciated!

Q1/ yes
Q2/ yes if you want a deodexed Rom
Q3/you don't need to deodex twframework and framework-res ...
Q4/ you need to backsmali every files. You can rename out folders to core, android.policy, ... And replace out with the "name of folder" in smali command. Classes.dex is specific of 1 file

Q5Yes, you can delete odex files. This is the point of deodexing

Q6/ you can do the 2 ways, to try if deodexed files are correct, then correct the permissions and then backup and delete odex file. But for entire rom, the better is to use a non wipe script and to flash the entire deodexed Rom.

Finaly, there are many deodexing auto kit. I made an How to deodex resign and zipalign a customRom, try the kit-Deodexage included.
Or look for more used deodex script cause there are many apks to deodex, doing this manually will be very long ...

Sent from my GT-I9100 using xda premium
 
  • Like
Reactions: mcheat and Arhtard

Top Liked Posts

  • There are no posts matching your filters.
  • 172
    The purpose of this thread is to give basics to manually deodex and odexing back framework and apk files

    Credits and Thanks to :
    jubeh
    Decad3nce
    software_samurai
    JKay
    LeoMar75

    and many others I forgot


    Theory :
    WHAT IS AN ODEX FILE?

    In Android file system, applications and framework files come in packages with the extension .apk or .jar. These APKs or JARs contain certain .odex files whose supposed function is to save space. These ‘odex’ files are actually collections of parts of an application that are optimized before booting. Doing so speeds up the boot process, as it preloads part of an application. On the other hand, it also makes hacking those applications difficult because a part of the coding has already been extracted to another location before execution.

    THEN COMES DEODEX

    Deodexing is basically repackaging of these APKs or JARs in a certain way, such that the .odex files are reassembled into classes.dex files directly integrated inside the APKs or JARs. By doing that, all pieces of an application package are put together back in one place.
    For now, we need Baksmali.jar and Smali.jar to deodex, it seems these tools are not perfect and it seems to be why deodexed stock browser is laging/freezing.
    This is the reason why there is a return to odexed customROMs


    Prerequisites :

    You will need these files :
    * backsmali.jar
    * smali.jar
    * custom java.awt.jar
    * dexopt wrapper
    * recent version of busybox
    all included in the attached .zip (end of post)

    You will also need :
    * your GS2
    * with the official odexed firmware you want to mod
    * rooted and with root explorer (pay app but really usefull) and with CWM recovery (better :))
    * ADB installed and working in su (#)
    * copy dexopt-wrapper in /system/bin/ and giving it 755 permissions (using root explorer or command: chmod 755 /system/bin/dexopt-wrapper
    * optional (if errors during odexing back) overwrite installed busybox with the one included here in /system/xbin/

    You have to know :
    * even on stock firmware (odexed) there are some deodexed .apk (like framework-res.apk in /system/framework/ and like some .apk in system/app/)

    Tip on Windows "Vista / 7" : open a CMD prompt in a specified folder
    1. Select the folder you want to open in the command prompt
    2. Right-click on it while holding the Shift key
    3. Select Open command window here



    Manually Deodexing :

    theory :
    to decompil an odex file you need Baksmali.jar and you needs the BOOTCLASSPATH
    BOOTCLASSPATH is a list in specific order of some framework .jar files

    ** To decompil and re-odex back .odex from JAR file you need to use the BOOTCLASSPATH specified in the init.rc file located in the root folder of your GS2 : (open init.rc with notepad ++)

    Extract of I9100 init.rc :
    export BOOTCLASSPATH /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar

    ** To decompil an .odex from APK file, BOOTCLASSPATH is different in fonction of the APKs, so the lazy way is to include all the .JAR files of the framework folder
    2 applications : Emails.apk and MobilePrint.apk needs one more custom java.awt.jar


    1/ put in the same folder :
    * apk to deodex
    * all system/framework files
    add :
    * custom java.awt.jar
    * baksami.jar
    * smali.jar
    * zipalign.exe

    2/ open CMD prompt in this folder (see above for how to)

    3/ Deodexing Framework file (I will take android.policy.jar for example) :

    * BAKSMALI of the android.policy.odex :
    Code:
    java -Xmx1024m -jar baksmali.jar -c :core.jar:bouncycastle.jar:ext.jar:framework.jar:android.policy.jar:services.jar:core-junit.jar -x [B]android.policy.odex[/B]

    * This create an out folder. You can now modify some files (like adding Advanced power menu)

    * SMALI the /out folder in a classes.dex file :
    Code:
    java -Xmx1024m -jar smali.jar [B]out[/B] -o classes.dex

    * finally deodex your android.policy.jar :
    open android.policy.jar with 7zip without extracting
    push the classes.dex created in the 7zip window in the root folder
    close the 7zip windows and here is your deodexed android.policy.jar :)


    4/ Deodexing APK in system/app (I will take SystemUI.apk for exemple) :

    * BAKSMALI of the SystemUI.odex :
    Code:
    java -Xmx1024m -jar baksmali.jar -c :am.jar:android.policy.jar:android.test.runner.jar:bmgr.jar:bouncycastle.jar:com.android.location.provider.jar:com.google.android.maps.jar:com.samsung.device.jar:com.yamaha.android.media.jar:core.jar:core-junit.jar:ext.jar:framework.jar:ime.jar:input.jar:[B]java.awt.jar[/B]:javax.obex.jar:libvtmanagerjar.jar:monkey.jar:pm.jar:sec_feature.jar:seccamera.jar:sechardware.jar:secmediarecorder.jar:services.jar:sqlite-jdbc.jar:svc.jar:twframework.jar -x [B]SystemUI.odex[/B]

    * an out folder is created. You can modify the files inside if you want.

    * SMALI the /out folder in a classes.dex file :
    Code:
    java -Xmx1024m -jar smali.jar [B]out[/B] -o classes.dex

    * finally deodex your SystemUI.apk :
    open SystemUI.apk with 7zip without extracting
    push the classes.dex created in the 7zip window in the root folder
    close the 7zip windows and here is your deodexed SystemUI.apk :)

    * extra step for APKs : zipaplign of your new deodexed SystemUI.apk
    --> In the same CMD prompt windows, type :
    Code:
    zipalign -v 4 SystemUI.apk zip_SystemUI.apk
    A zip_SystemUI.apk file is created. Delete your deodexed SystemUI.apk and rename zip_SystemUI.apk in SystemUI.apk



    ODEXING BACK :

    the theory :
    *You will need to copy the (custom) deodexed file (.jar or .apk) in the system/framework/ folder of your phone.
    *You will use dexopt wrapper (already copied in your phone) to obtain a new .odex file (patched_android.policy.odex for example)
    * You will copy the signature of original .odex file to patched.odex file - if not, the phone won't boot ...

    How To :
    1/ backup your original files (apk jar and odex) to /sdcard/Mod/
    2/ copy modified deodexed files (.apk and .jar) in /system/framework/ of your GS2

    Now we are going to odex back :)

    3/ open a CMD prompt in the folder of adb.exe (usualy /android-sdk-windows/platform-tools/)
    4/ type command :
    Code:
    adb shell
    su
    ## for .JAR file :
    dexopt-wrapper /system/framework/XXX.jar /system/framework/patched_XXX.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
    
    response must be :
    --- BEGIN '/system/framework/android.policy.jar' (bootstrap=0) ---
    --- waiting for verify+opt, pid=7194
    --- would reduce privs here
    --- END '/system/framework/android.policy.jar' (success) ---
    
    ## for .APK file :
    dexopt-wrapper /system/framework/XXX.apk /system/framework/patched_XXX.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
    --> This will create the patched_XXX.odex file

    Now we need to copy signature from original .odex file to patched .odex file cause Dalvik need files signature integrity in order to boot.

    5/ always in the same CMD prompt windows :
    Code:
    # if not already done ...
    adb shell
    su
    
    # copy the original .odex and .jar in system/framework (not .apk) : 
    cp /sdcard/MOD/original.XXX.odex /system/framework
    cp -f /sdcard/MOD/XXX.jar /system/framework   # where XXX.jar is the original odexed .jar
    
    # give all permissions to XXX.odex files :
    chmod 777 /system/framework/original.XXX.odex
    chmod 777 /system/framework/patched_XXX.odex
    
    # copy signature :
    busybox dd if=/system/framework/original.XXX.odex of=/system/framework/patched_XXX.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
    
    response must be :
    busybox dd if=/system/framework/original.XXX.odex of=/system/framewor
    k/patched_XXX.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
    20+0 records in
    20+0 records out
    20 bytes (20B) copied, 0.002042 seconds, 9.6KB/s

    Now the signature is copied over the patched_XXX.odex

    Notice :
    a - if you don't have response after busybox dd command : busybox is not installed or you have a to old version, use the busybox included in the attached .zip
    b - if you don't have the last response line : 20 byt
    3
    odexing back or reodexing notes

    Adding some info regarding reodexing on ice cream sandwich 4.0.3. sicopat has a great guide here, it got me 98% toward adding custom frameworks to the stock (emulator) rom. I ran one issue and I have a couple suggestions:

    1) dep signature checks failed for patched odex files.

    This was caused by my custom framework.jar hanging out in /system/framework when I restarted android. You need to make sure the original (stock) jar is in /system/framework next to your custom odex when you restart android. It looks like the SHA-1 checksum of this jar file is recomputed at boot and is inserted into your odex which overwrites the signature you so diligently copied over per sicopat's instructions. After you run dexopt-wrapper to generate your new odex, you should rm your custom jar.

    2) you can avoid installing busy box on the device by adb pulling back the needed odex files (original stock odex and your new custom odex) and running dd on your host machine (you are using linux right?).

    3) to avoid confusion with BOOTCLASSPATH, you should just use it directly in your call to dexopt-wrapper. So from an adb shell:

    dexopt-wrapper customjar.jar customjar.odex $BOOTCLASSPATH

    $BOOTCLASSPATH is exported by init and should be available to your adb environment. Using it directly saves some typing and makes your call to dexopt-wrapper less error prone.

    Hope this helps somebody.
    2
    Great ! I was looking for this, thank you.

    One thing was still giving me a hard time and i got that one solved also.
    When doing a odex back from a custom theme, the method is different.

    Because you need to use the modified framework file in the dependencylist.
    So for me it was:

    (I put a modified framework.jar in /sdcard)


    dexopt-wrapper /sdcard/framework.jar /sdcard/framework.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/sdcard/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar


    Otherwise it does NOT work. Now i have succusfully added overglow to a odex ROM. :D
    2
    ok i have a few questions if you wouldnt mind helping.
    i've been using androids since July of this year, only 2 months now, so i'm really new to modding...
    i'm trying very hard to catch on and to learn...
    unfortunately, i purchased a device with absolutely no development

    anyway, assuming that you'll help, i'll proceed...

    i'm not on a galaxy s II - i'm doing this on a gravity smart.

    our bootclass path is different:
    system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
    your bootclass path:
    /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar

    so i removed the difference in your command example to this:
    java -Xmx1024m -jar baksmali.jar -c :core.jar:framework.jar:android.policy.jar:services.jar -x android.policy.odex

    all is fine, i get an "out" folder created with files in it
    i then use your command example:
    java -Xmx1024m -jar smali.jar out -o classes.dex
    and a classes.dex is created
    i then opened the android.policy.jar with 7zip and dropped the classes.dex file in its root
    i'm assuming the process is going as its supposed to at this point.

    question 1: am i doing this right?

    question 2: do i do this to all the .jars in the /system/framework/ directory to have a completely deodexed system (and of course all the /system/app/files)?

    question 3: do i also use these methods or the apk methods listed on your 2nd post to do the twframework-res.apk file?

    question 4: do i create a new "out" folder for each .jar (run the command line for each .jar) or do i use the first created classes.dex for all the .jar files in /system/framework/ directory?

    question 5: after i create the deodexed files i can safely delete the .odex companion files correct? (this may be a dumb question with an obvious answer, but i don't want to screw up)

    question 6: can i place the deodexed files on the sdcard and move them with root explorer or do i need to push them thru using ADB?

    any help or suggestions would be greatly appreciated!

    Q1/ yes
    Q2/ yes if you want a deodexed Rom
    Q3/you don't need to deodex twframework and framework-res ...
    Q4/ you need to backsmali every files. You can rename out folders to core, android.policy, ... And replace out with the "name of folder" in smali command. Classes.dex is specific of 1 file

    Q5Yes, you can delete odex files. This is the point of deodexing

    Q6/ you can do the 2 ways, to try if deodexed files are correct, then correct the permissions and then backup and delete odex file. But for entire rom, the better is to use a non wipe script and to flash the entire deodexed Rom.

    Finaly, there are many deodexing auto kit. I made an How to deodex resign and zipalign a customRom, try the kit-Deodexage included.
    Or look for more used deodex script cause there are many apks to deodex, doing this manually will be very long ...

    Sent from my GT-I9100 using xda premium
    1
    Awesome! Thank you for your time sir!

    Best regards,
    aDEO