Develop Bugs

[HowTo] Deodex your Xoom the Long Way (Mac OSX / Windows)

MAC/ LINUX Instructions
How to Deodex your Xoom the long way:
Requirements:
1) Have a knowledge of ADB and have it set up on your computer
2) Have smali and baksmali on your computer. I used the ones attached below.
3) If on a Mac, download betterzip, Windows, download 7Zip or WinRar
Steps:
1) First, you must pull your system apps and framework from your xoom. To accomplish this, navigate to where ADB is located and do the following:
Code:
adb pull /system/app/ <output directory>/app
example: adb pull /system/app /Users/dhemke17/Desktop/system_dump/app/
adb pull /system/framework/ /<output directory>/framework
example: adb pull /system/app/ /Users/dhemke17/Desktop/system_dump/framework
2) Now that you have your apps and framework, you can begin working…this is a pretty lengthy process so bare with me…
3) Place both smali.jar and baksmali.jar into the folder where your framework is. And do the following commands. (These are for a mac and may need to be altered for Windows). You must change the xxxx.odex to the desired odex file and substitute in your output directory
Code:
java –jar baksmali.jar –o temp1 –x xxxx.odex
cd <output directory>/framework/temp1
find ./ -type f -exec sed -i -e 's/return-void-barrier/return-void/g' {} \;
cd <output directory>/framework/
java -Xmx512M -jar smali.jar temp1 -o classes.dex
rm –rf temp1
4) Once these steps are completed, you have a classes.dex folder in your framework folder. Using BetterZip (7-Zip) Open the initial jar file (example: if you just deodexed am.odex, open am.jar) and place the classes.dex into the root of the archive (do not place it in any folder) and then delete the classes.dex file. This will work for all framework files but framework.jar, policy.jar, services.jar, and ext.jar. For these, do the following: just replace xxxxx with each of the 4 corresponding . odex files.
Code:
java -jar baksmali.jar -c :core-junit.jar:framework.jar -o temp1 -x xxxxx.odex
cd <output directory>/framework/temp1
find ./ -type f -exec sed -i -e 's/return-void-barrier/return-void/g' {} \;
cd <output directory>/framework/
java -Xmx512M -jar smali.jar temp1 -o classes.dex
rm –rf temp1
5) Once completed, create a folder named frame_done and copy the deodexed framework files into it.
6) Copy all of the framework files into the <output directory>/app folder as they are needed to deodex the system apps.
7) Copy your baksmali.jar and smali.jar into the <output directory>/app folder as well.
8) To deodex the system apps, do the following. Be sure to replace xxxx.odex with the desired odex file.
Code:
java -jar baksmali.jar -c :com.android.location.provider.jar:javax.obex.jar:core.jar:apache-xml.jar:bouncycastle.jar -o temp1 -x xxxx.odex
cd <output directory>/app/temp1;
find ./ -type f -exec sed -i -e 's/return-void-barrier/return-void/g' {} \;
cd <output directory>/app/;
java -Xmx512M -jar smali.jar temp1 -o classes.dex
rm -rf temp1
9) At this point, it’s a repeat story. Just open the corresponding .apk file and drop the classes.dex into archive’s root and then delete the classes.dex file. Continue steps 8 and 9 until all of your system apps are deodexed. Create a folder named app_done and move all of the completed apk files into it.
10) Now you have a completely deodexed system and framework in separate folders. To get them onto your xoom, you can use the following update.zip, just be sure to place your apps into the /system/app folder and your framework into the /system/framework folder. Flash the update.zip in CWR and reboot. Your system will now be deodexed!
Update.zip for you to drop your framework and apps into:
Deodex.zip
Helpful hints:
For a mac, for the steps after the baksmali step, you can create a script to do the rest, besides moving anything. Mine can be downloaded but needs to be modified to your output directory/temp1 and output directory in two different spots, then you can just do the following:
Code:
java –jar baksmali.jar –o temp1 –x xxxx.odex
bash deodex.sh
My Script:
deodex.sh
Baksmali is attached in a zip file below...be sure to extract and rename it to baksmali.jar
Smali.jar
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Windows Instructions
Requirements:
1) Know how to use adb and have it set up
2) Have Baksmali and smali.jars installed
3) Have 7-Zip or WinRAR
4) Must have Cygwin installed...steps are below
Procedure to install Cygwin (Thanks dsixda):
1. Download and install the Java JDK for Windows 32-bit from java.sun.com (WARNING: Do not install Cygwin before the JDK!!)
2. (Install the JDK in Step 1 before you proceed to this step!!)
3. Download the file cygwin_packages.zip, unzip it and follow the instructions in the "kitchen_readme.txt" file to install a customized version of Cygwin. Done!!
NOTE: A default install of Cygwin will not work, you need to use the customized version described in the guide.
NOTE2: If you had installed Java after Cygwin, then Cygwin may have issues finding the Java executable file, which will require an edit of the .bash_profile file. See here to fix it.
Procedure to Deodex:
1) First, you must pull your system apps and framework from your xoom. To accomplish this, navigate to where ADB is located and do the following:
Code:
adb pull /system/app/ <output directory>/app
example: adb pull /system/app /Users/dhemke17/Desktop/system_dump/app/
adb pull /system/framework/ /<output directory>/framework
example: adb pull /system/app/ /Users/dhemke17/Desktop/system_dump/framework
2) Place both smali.jar and baksmali.jar into the folder where your framework is. And do the following commands. (These are for a mac and may need to be altered for Windows). You must change the xxxx.odex to the desired odex file and substitute in your output directory. Notice, in the find command line, -e has been removed as it is not needed.
Code:
java –jar baksmali.jar –o temp1 –x xxxx.odex
cd <output directory>/framework/temp1
find ./ -type f -exec sed -i 's/return-void-barrier/return-void/g' {} \;
cd <output directory>/framework/
java -Xmx512M -jar smali.jar temp1 -o classes.dex
rm –rf temp1
3) Follow Steps 4 - 10 From the mac instructions MAKING SURE YOU MAKE THE CHANGE TO THE FIND LINE INDICATED ABOVE
If there is anything you are unsure about and you get confused, please feel free to PM me, or ask on this board...
If this post has helped you, and you feel so inclined to do so, you can hit the thanks button, or if you are really excited, you can donate to me here: Donate HERE

Thanks for the guide. Happy to see another dev with a Xoom. Obviously we have to ask you for a rom now
Sent from my Thunderbolt using Tapatalk

Lol...well idk about that...maybe someday, but for now this will work. I got an already deodexed system/ pretty heavily themes "Rom" linked for for WiFi only devices, but its more or less just a tool for others to use.
Sent from my ADR6400L using XDA App

Cool thanks again, I'm a wifi only Guy as well, we get no love around here, lol.
Sent from my Thunderbolt using Tapatalk

lrs421 said:
Cool thanks again, I'm a wifi only Guy as well, we get no love around here, lol.
Sent from my Thunderbolt using Tapatalk
Click to expand...
Click to collapse
It's all I have, so if I put anything out, it will most definitely be for that.

Updated for Windows...

thanks for the guide. will look at doing it once I have the time to dedicate to it!

The links for baksmali.jar and deodex.sh are broken.

woolmonkey said:
The links for baksmali.jar and deodex.sh are broken.
Click to expand...
Click to collapse
Fixed it...

Thanks and am.jar at least for 3.2 needs
Code:
java -jar baksmali.jar -c :core-junit.jar:framework.jar -o temp1 -x xxxx.odex

Mine didn't I have the entire framework and system done and I am going to be uploading it in a couple hours. If you can, try and deodex VoiceSearch.odex, I can't seem to get it to go.
Posted the stock 3.2 Rom deodexed for anyone that wants to use it for anything...It is required that you already be on 3.2 and rooted...easiest way to do this is posted by solarnz

Yah I have everything done now except VoiceSearch.

Did you manage to get VoiceSearch done? I;ve tried some things with no success. Also do you zipalign afterwords?

woolmonkey said:
Did you manage to get VoiceSearch done? I;ve tried some things with no success. Also do you zipalign afterwords?
Click to expand...
Click to collapse
didn't zipalign...not sure how to on xoom...

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

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
Click to expand...
Click to collapse
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
Click to expand...
Click to collapse
Prerequisites :
You will need these files :
* backsmali.jar
* smali.jar
* custom java.awt.jar
* dexopt wrapper
* recent version of busybox
Click to expand...
Click to collapse
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/
Click to expand...
Click to collapse
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
Click to expand...
Click to collapse
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
Click to expand...
Click to collapse
1/ put in the same folder :
* apk to deodex
* all system/framework files
add :
* custom java.awt.jar
* baksami.jar
* smali.jar
* zipalign.exe
Click to expand...
Click to collapse
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
Click to expand...
Click to collapse
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
Click to expand...
Click to collapse
* 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 ...
Click to expand...
Click to collapse
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

Awesome! Thank you for your time sir!
Best regards,
aDEO

awesome man!'help me out of questions!

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.

nice tutorial
I've successfully deodex them.
lets try odex them back .

Mekrel said:
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.
Click to expand...
Click to collapse
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

abu2x said:
nice tutorial
I've successfully deodex them.
lets try odex them back .
Click to expand...
Click to collapse
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

brilliant! thx a ton!

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.

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.

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

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.

Brotuck said:
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.
Click to expand...
Click to collapse
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 ??

smali / baksmali v1.2.8 is available

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:
Sets permisions for the dexopt-wrapper and zip binaries.
Odexes the core framework in the same order they're listed in BOOTCLASSPATH in init.rc.
Odexes the other framework files that were not previously odexed
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?
Many thanks
Mark

Mekrel said:
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:
Sets permisions for the dexopt-wrapper and zip binaries.
Odexes the core framework in the same order they're listed in BOOTCLASSPATH in init.rc.
Odexes the other framework files that were not previously odexed
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?
Many thanks
Mark
Click to expand...
Click to collapse
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.

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?

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!

NitroOnTheRocks said:
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?
Click to expand...
Click to collapse
Nope
Sent from my GT-I9100 using xda premium

Arhtard said:
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!
Click to expand...
Click to collapse
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

Google Wallet Help (ADB Shell related)

I'm going through these instructions but they are pretty complicated for me.
lukegb said:
Instructions for getting rid of ZIP version only <4.0.3:
Open ClockworkMod Recovery
Download the correct files from http://googlewallet.lukegb.com/stock/system/ that match your Android build and system - ICL53F is Android 4.0.2, yakju is GSM and mysid is LTE.
You'll need:
NfcGoogle.apk
com.android.nfc_extras.jar
Open an adb shell from your computer to your device from the directory you've just downloaded those files to
Run (on device via adb shell):
Code:
mount /system
mount /data
rm /system/app/Wallet.*
rm /system/app/NfcGoogle.*
rm /system/framework/com.android.nfc_extras.*
exit
Run (on computer):
Code:
adb pull /data/system/packages.xml packages.xml
Make a backup of the newly-created packages.xml file which is on your computer
Open packages.xml in a text editor (which isn't notepad)
Copy ALL the content
Open http://googlewallet.lukegb.com/gn_packages_xml_fixer.html in a web browser
Paste the content into the left-hand "Input" box
Click "Fix it"
Copy ALL the content from the right-hand "Output" box
Delete all the content in the text editor with packages.xml open
Paste the content
Save packages.xml
Close your text editor
Run (on computer):
Code:
adb push NfcGoogle.apk /system/app/NfcGoogle.apk
adb push com.android.nfc_extras.jar /system/framework/com.android.nfc_extras.jar
adb push packages.xml /data/system/packages.xml
adb shell chmod 644 /system/app/NfcGoogle.apk
adb shell chmod 644 /system/framework/com.android.nfc_extras.jar
You're done.
EDIT (28/12/11)
Important notice for all those who have already attempted to remove the ZIP version to replace with the APK version
Read this if NFC has disappeared from your more menu, you get crashes in the More menu, Wallet now forcecloses where it didn't before after removing the ZIP
I have just (idiotically) noticed a blindingly obvious flaw with the files I had previously uploaded to the stock folder on http://googlewallet.lukegb.com - they were the odexed versions of the files, crucially WITHOUT the .odex files. I've replaced them with pseudo-stock (same signatures) versions of the apks and if you replace the NfcGoogle.apk, Android should correctly take this into account.
Don't forget to chmod 644 the NfcGoogle apk and the com.android.nfc_extras.jar files!
Click to expand...
Click to collapse
I'm stumped here: Open an adb shell from your computer to your device from the directory you've just downloaded those files to
I can open cmd and open adb shell but i don't understand how to open adb from the directory where i donwloaded said files.

[HOWTO] / [GUIDE] Compile Loki_patch and execute

Things you will need:
Cygwin- http://www.cygwin.com/setup.exe
ADB- http://developer.android.com/sdk/index.html
Loki Patch source- https://github.com/djrbliss/loki
These are the steps i took to compile and use loki_patch.
I will assume you have the android sdk setup and ready, I will assume your SDK is under c:/AndroidSDK(this is how mine is setup)
Pulling aboot.img using adb:
You can copy cmd.exe into the folder where adb is located and run it from there so you do not have to navigate to the folder manually, or just run cmd.exe and navigate to the adb folder, for me it is c:\AndroidSDK\sdk\platform-tools.
Once you are in your adb file path and your phone is connected and in debug mode follow these instructions to pull aboot.img from your phone.
Original instructions from djrbliss here https://github.com/djrbliss/loki
[email protected]:~$ adb shell
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/block/platform/msm_sdcc.1/by-name/aboot of=/data/local/tmp/aboot.img
[email protected]:/ # chmod 644 /data/local/tmp/aboot.img
[email protected]:/ # exit
[email protected]:/ $ exit
[email protected]:~$ adb pull /data/local/tmp/aboot.img
3293 KB/s (2097152 bytes in 0.621s)
Now you should have the file aboot.img in the platform-tools folder(where the adb.exe file is located)
Copy this file to your desktop so you know where it is.
Installing gcc with Cygwin:
Original Instructions came from here http://www.eecg.utoronto.ca/~aamodt/ece242/cygwin.html
Step 0: Download and run the cygwin installer.
Step 1: Select “Install from Internet”
Step 2: Install to default location
Step 3: Use default local package directory (click next)
Step 4: Use whatever internet connection settings (click next)
Step 5: Select a mirror (use the one already selected, click next)
Step 6 (a): In the “Select Packages” expand “Devel”:
Step 6 (b): Select gcc, gdb, and make
Step 7: click next and follow the rest of the installation instructions.
Ok, now that gcc is installed we can compile the loki_patch source to make the executable.
Go here https://github.com/djrbliss/loki
You should see a file called loki_patch.c, click this link and it will open and you can see all the code.
Select the code from top to bottom and right click, copy.
Now right click on your desktop and select new> text file.
Open this text file and paste the code into it, go to file and save as loki_patch.c (make sure you have your file extensions turned on so you can save this as a c source and not a txt file).
We should now have a file called loki_patch.c on the desktop, keep it there for now.
Open up windows explorer and navigate to the following:
c:\cygwin\home\<username>\
(You will see a few files and a kitchen folder)
Create a new folder in here called compile.
Now, let's go back to the desktop and copy loki_patch.c and aboot.img and paste those into the compile folder you just created.
Go ahead and run cygwin.
Now we need to change directories, so let's type the following:
cd compile
We should now be in the compile folder.
Lets compile this code so we can use it, type the following command:
gcc loki_patch.c -o loki_patch
We should now have a file in the compile folder called loki_patch.exe( windows added this .exe, the file extension can be left alone or deleted)
Now you need a boot.img file to patch, grab one from a rom or kernal and copy this into the compile folder.
Once all the files are in the compile folder run the following command to patch the boot.img file:
./loki_patch boot aboot.img boot.img boot.lok
We should now have a boot.lok file in the compile folder, hope this helps and i hope i didnt leave anything out, i will try and update this with screen shots later.

Nice work..thanks

C13v3r0n3 first link is Broken: Cygwin, my friend!!

TheAxman said:
Nice work..thanks
Click to expand...
Click to collapse
And that's why you guys rock because that's all greek to me.
"If you ain't first yer last"
Sent from my rockin ATT S4

{Tutorial}Push APK files using ADB

Here's what you need to know to start on this adventure:Knowledge of: Android SDK, command prompt, adb push (command), adb pull (command), setting permissions in adb shell (chmod), apktool (compiling/decompiling), 7zip, Notepad++ or equivalent.
Pushing the file to our phone
Here I am taking SystemUI.apk as an example.
Plug in your phone to your computer.
Open command prompt, and change directories to your Android SDK - platform-tools directory(mine is at: C:\sdk\platform-tools).]
Type: adb reboot recovery
On your phone, mount /system. If you don't, you won't be able to access/make changes to /system.
Type: adb shell
Type:cd /system/app
Type:mv SystemUI.apk SystemUI.bak
NOTE: This copies your existing phone's SystemUI.apk to a file named SystemUI.bak. We are backing up our file, I HIGHLY RECOMMEND THIS.
Type: exit
Type:adb push SystemUI.apk /system/app/
Type:adb shell
Type: chmod 0644 /system/app/SystemUI.apk
Type:exit
Click to expand...
Click to collapse
Now, reboot your phone normally.
Now, if you screwed up and you need to revert back to your original SystemUI.apk before we pushed the new one, here's how:
Type: adb reboot recovery
On your phone, mount /system.
Type: adb shell
Type: cd /system/app/
Type: rm SystemUI.apk
NOTE: This deletes your newly pushed SystemUI.apk file.
Type: mv SystemUI.bak SystemUI.apk
Type: exit
Reboot your phone normally. Notice we did not do the permissions chmod command again. Why not? We don't have to since copying the file retains its permissions. We only need to do this when pushing a new file to the system.
Click to expand...
Click to collapse
Press thanks.!!! if i've helped..!!​

True $tar said:
Here's what you need to know to start on this adventure:
Click to expand...
Click to collapse
There's already a guide available with a complete list of adb commands.See here
Use the power of search button before making new threads !

Mod Edit
As has been suggested , there is already a thread on this subject.
Thread closed
malybru
Forum Moderator