[Hero CDMA Q&A, Help & Troubleshooting] JsChiSurf:
Deodexing Scripts

Okay, probably not necessarily the correct thread for this but attached is a small tar file with 3 shell scripts that I use to deodex 'framework' and 'app', in a mostly automated fashion.

Create a new directory and untar the attached scripts into the new folder on your system (remove .txt extension from attached tar file).

tar -xvf deodex.tar

My scripts assume all of the necessary helper files are either in your PATH, or in the same folder where the scripts are being extracted into. So, be sure to either update your PATH, or copy / symbolic link 'adb', 'baksmali', and 'smali' to the working folder. The script also assumes that it has adequate permissions to run adb, etc. So, after extracting, from your working folder run 'adb shell' or something similar to verify you can establish a connection with the phone. This is only necessary, as you will see later, if the scripts need to connection to your phone to 'adb pull' the necessary files.

After extracting make sure the scripts are executable as well:

chmod +x *.sh

There is not a lot of error checking, so if something goes wrong, everything that follows will fail miserably as well :-)

The scripts, by default, will baksmali, smali, and then inject the necessary dex file into its corresponding jar/apk file. This does so using 7zip, so be sure to either download 7zip for Linux (making sure it too is in your PATH), or comment out the blocks in 'framework.sh' and 'app.sh' where 7zip updates the archives. If commenting out, you will need to manually update the archives afterwards.

EDIT: The script has been tweaked to support the stock Zip binary typically distributed with Linux. The default is to still use 7zip, however, you can comment out the block in framework.sh and app.sh that instructs to use 7zip in favor of stock Zip (see below).

What it's doing

process.sh is simply a wrapper script that runs runs 'framework.sh' and app.sh', and then the resultant RunFramework.sh and RunApp.sh files that framework.sh and app.sh dynamically generates. You can either run process.sh to run everything at once, or manually run 'framework.sh' and 'app.sh', followed by RunFramework.sh and RunApp.sh individually, to process just their applicable files.

framework.sh will look for a sub-folder in your working directory named 'framework'. If NOT present, it will attempt to adb pull /system/framework from your phone when connected. app.sh will do the same thing for /system/app. So, if you don't want to pull from a connected phone, be sure to manually create 'framework' and 'app' sub-folders in your working directory, and populate these folders with the apk/jar/odex files you intend to process. If 'app' and 'framework' sub-folders are already present, the script will skip the 'adb pull' portion, so be sure that ALL of your jar/apk/odex files are in their respective sub-folders if populating them manually.

Once the pull has finished (assuming the directories / files are not already present), the respective scripts will analyze the contents of the 'framework' and 'app' folders, looping through and auto-generating new scripts (RunFramework.sh and RunApp.sh) with the necessary commands to baksmali/smali/7zip each applicable odex file in its folder. framework.sh and app.sh will also create a sub-folder in the 'framework' and 'app' folder named 'output' and in this folder, more sub-folders in the name of the odex file, where baksmalil will output its contents, and where smali will generate its dex file.

Once these files are generated (RunFramework.sh and RunApp.sh) by 'framework.sh' and 'app.sh', you can then run them manually to deodex the files, or, they will be automatically launched if run from the wrapper script 'process.sh'.

Do not delete the contents of your 'framework' and 'app' sub-folders until the entire process for both folders complete, as 'apps' needs the jar files in framework to satisfy its dependencies.

Once the entire process completes, you can then delete all of the .odex files in the 'framework' and 'app' sub-folders, as each applicable jar/apk will have its corresponding classes.dex file inserted, assuming everything worked as planned. Odds are there will be some failures, so pay attention to your screen, as you may need to manually run and tweak settings, but this should complete 95% of the legwork.

If you open 'framework.sh' or 'app.sh', there are some variables set at the top of the scripts that you can adjust such as:

framework.sh:

#colon delimited list of dependencies for any/all odex files to process, modify as necessary
dependencies=":com.htc.framework.jar"

#set name of baksmali/smali jar files
baksmali="baksmali-1.2.1.jar"
smali="smali-1.2.1.jar"

#set memory switch for java vm
mem="-Xmx512m"

#define default zip binary to use
zipbin="7z a -tzip"
ziptail="-mx5"
#zipbin="zip -u"
#ziptail=""

app.sh

#colon delimted list of dependencies for any/all odex files to process, modify as necessary
dependencies=":com.htc.framework.jar:com.google.android.maps.jar:com.htc.android.pimlib.jar:javax.obex.jar"

#set name of baksmalil/smali jar files
baksmali="baksmali-1.2.1.jar"
smali="smali-1.2.1.jar"

#set memory switch for java vm
mem="-Xmx512m"

#define default zip binary to use
zipbin="7z a -tzip"
ziptail="-mx5"
#zipbin="zip -u"
#ziptail=""

The default settings are what I am using for deodexing the Android 2.1 Eris port. You may need to adjust as necessary depending on your version's dependencies, etc.

You can adjust the 'dependencies' variable, the name of the 'baksmali' and 'smali' jar files used (if you have renamed, etc), the memory settings to use for passing to the java vm, as well as the zip binary to use.

The scripts use the latest version of baksmali/smali, so the deodexerant helper application on the phone is not needed, and an active connection is therefore not required via adb to the phone during deodexing, unless, of course, you need to pull the files from your phone in the first place.

I think that's it. Hopefully the files, at a minimum, work as a starting point for you to automate the process. Certainly tweak as necessary to conform to your environment. There's certainly more than one way to skin a cat, and I probably could have done things more efficiently if I spent the time, but hey, it works for me :).