Related
Hi Guys,
I was speaking to baadnwz a couple of weeks ago and i asked him which script he used to properly pack all the APKs in his ROM. He told me he used no script, just repacked the APKs he thought were most relevant.
I figured it couldn't be too hard to write something that took an APK, extracted it somewhere, then repacked it with the proper compression, so i wrote one. baadnwz then challenged me to make it work for multiple APKs, so he can just run it against a folder full of them like a lazy asshole. i went one better, and made a script that you could run against a ROM folder structure, it will search out all APKs, repack them, and copy them back into place. HOT!
because this uses recursion and functions to make it easier to write (and because i'm generally comfortable in it), i have written it in VBScript. So this means it won't work on linux as far as i know, sorry. Feel free to convert it or whatevs
WHAT DOES IT DO??????//
1. finds an APK
2. unpacks it in a folder
3. optimises the PNGs (if you want it to)
4. repacks all files as deflate except a blacklist of filetypes*
5. repacks the blacklisted filetypes* as STORE
6. zipaligns the new APK
7. copies it back to the original location, overwriting the original APK
8. finds the next APK, and repeat from step 2
* the blacklisted file types are easily editable. just find the STOREFileNames variable. by default the filetypes are:
"*.arsc", "*.m10", "*.png", "*.wav", "*.ogg", "*.mp4", "*.jpl", "*.jpeg", "*.gif","*.mp2", "*.mp3", _
"*.aac","*.mpg", "*.mpeg", "*.mid", "*.midi", "*.smf", "*.jet","*.rtttl", "*.imy", "*.xmf", _
"*.m4a","*.m4v", "*.3gp", "*.3gpp", "*.3g2", "*.3gpp2", "*.amr", "*.awb", "*.wma", "*.wmv", _
"*.so", "*.dat", "*.bin"
WHY DO YOU WANT THIS??
If certain filetypes in the APK are compressed as STORE (which means they aren't compressed at all), then Android can use them directly. If they are stored as DEFLATE (like all other file types should be), then Android must first decompress the APK somewhere. This means slower apps, more cache, and it's just not how things are supposed to be done. This script makes sure that all files inside all APKs are stored as they should be, and it will optimise PNG files and zipalign the final APK as it goes.
This script is really meant for ROM chefs to run against their ROMs before releasing them, but if you (a mere user) have a ROM that your chef hasn't run this script on, then you can extract the ROM, run the script on it, then recompress the ROM and flash it.
HOW DOES IT DO IT?????///////
It uses the command line version of 7-Zip. Download it from here:
http://7-zip.org/download.html
It uses zipalign.exe from the android SDK. if you don't know where this comes from.. maybe you shouldn't be using this script
It uses a cool OptiPNG utility to optimise the PNGs if you want it to. This slows the processing down a lot.. but it's up to you if you wanna do it. You'll need to download the utility from here:
http://optipng.sourceforge.net/
WHAT DO I HAVE TO DO TO MAKE IT WORK//////?
Grab the script, put it in the same folder as the root of your ROM (the script will repack all APKs in the subfolders from where it's sitting, including the APKs in the folder the script is in).
open up the script, there are 5 variables you MUST verify, most likely you will have to change them.. unless you put things on a D and E drive and your name is Nick..
tempAPKextract = "E:\Temp\tempAPKExtract"
tempAPKBuild = "E:\Temp\tempAPKBuild"
sevenZipLoc = """D:\nick\android\7za\7za.exe"""
zipAlignLoc = """D:\nick\android\android-sdk-windows\tools\zipalign.exe"""
optiPNGLoc = """D:\android\7-zipA\ROM\optipng.exe"""
the first two temp ones can be anywhere.. just make sure at least the sub folders up to "tempAPK..." exist (eg in this case the E:\Temp folder must already be there)
the next three are the locations of the tools required for the script to work, edit to please!
Run the script. If you have set verboseOutput to true (it's false by default), then I would highly recommend you run the script from the commandline with the command:
cscript fixAllAPKs.vbs
anyways, hope it's useful to you.
DOWNLOAD
CHANGELOG????/
v1.5.1 - cleaned up some code, added in verboseOutput so you can watch the progress as it's fixing (must run as cscript!)
v1.5 - added OptiPNG to the script, enabled by default. Quite slow. Added some more file types.
v1.4.3 - added more file types to STORE, thanks gtg465x
v1.4.1 - minor code clean up, fixed some comments.
v1.4 - fixed the problem where the script wouldn't fix any APKs in the root folder that the script was in
v1.3 - almost doubled the speed of the script. fixed some naughty bugs
edit: nevermind
not from what i've been told. if it's not compressed, the android system doesn't have to explicitly decompress it somewhere when it wants to use it, it can just pick it straight out of the APK.
omniwolf said:
not from what i've been told. if it's not compressed, the android system doesn't have to explicitly decompress it somewhere when it wants to use it, it can just pick it straight out of the APK.
Click to expand...
Click to collapse
Good man. Here are all of the files blacklisted by the default Android Asset Packaging Tool (aapt) if you want to include them.
{
".jpg", ".jpeg", ".png", ".gif",
".wav", ".mp2", ".mp3", ".ogg", ".aac",
".mpg", ".mpeg", ".mid", ".midi", ".smf", ".jet",
".rtttl", ".imy", ".xmf", ".mp4", ".m4a",
".m4v", ".3gp", ".3gpp", ".3g2", ".3gpp2",
".amr", ".awb", ".wma", ".wmv"
};
cool, thanks for the info. i've added the missing ones in and uploaded a new version.
cheers!
Nice work.
Suggestion or maybe a challenge for Ver 2:
Given a definition of what languages the user defines, can you repack including only those languages. This would include both drawables and layout language folders.
Removing languages not only speeds up the rom but reduces the apk size which for Sense 3.0 is becoming challenging for many older (> 1 year) devices.
Thanks for your contributions to XDA.
Also need to add .so to the blacklist. Ran into a problem with that the other day.
Here's mine.
It synchronizes with our SVN repository and builds the rom. Any commits which were made are automatically turned into a new ClockWorkMod flashable package.
Code:
#! /bin/sh
#This is the repository Directory, change to match your setup
Repo="~/TeamKomin/trunk"
#This is the Final folder, this is where the file will end up
Output="~/Desktop"
#synchronize SVN repository
svn update "$Repo"
#remove temp folder if exist
test -e "$Output/tmp/" && rm -Rf "$Output/tmp/"
#make new temp folder
mkdir "$Output/tmp/"
#copy repository to temp folder
cp -rf "$Repo/data" "$Output/tmp/"
cp -rf "$Repo/META-INF" "$Output/tmp/"
cp -rf "$Repo/system" "$Output/tmp/"
cp -rf "$Repo/updates" "$Output/tmp/"
#clear SVN folders to reduce size
find "$Output/tmp/" -name ".svn" -type d -exec rm -rf {} \;
cd "$Output/tmp"
#remove old files if there
test -e "$Output/AndromedaRepo.zip" && rm -f "$Output/AndromedaRepo.zip"
#zip up a new Andromeda3 version
zip -r "$Output"/AndromedaRepo.zip ./*
#done
I've also got a version which uses the Expect command to log into our SFTP server and update the files.teamkomin.com website... I'm not posting that here though as it contains security sensitive information.
Using this method, all members work on the ROM as though it were on the phone... This script packages it. No need to package or unpackage the entire thing.
myn said:
Nice work.
Suggestion or maybe a challenge for Ver 2:
Given a definition of what languages the user defines, can you repack including only those languages. This would include both drawables and layout language folders.
Removing languages not only speeds up the rom but reduces the apk size which for Sense 3.0 is becoming challenging for many older (> 1 year) devices.
Click to expand...
Click to collapse
ok, sounds like a good idea. i'm not actually a ROM developer, so i don't know the ins and outs of the various files. any hints on which files i exclude for various languages? just having a vague look around i see in framework-res.apk there's some raw-ar, raw-cs, raw-en-GB folders, are these the ones you're saying i can strip out?
this will obviously be a lot easier if i can do it programmatically, do you know the rules?
Also need to add .so to the blacklist. Ran into a problem with that the other day.
Click to expand...
Click to collapse
ok cool, added it in and uploaded 1.4.3. thanks dude.
Here's mine.
It synchronizes with our SVN repository and builds the rom. Any commits which were made are automatically turned into a new ClockWorkMod flashable package.
I've also got a version which uses the Expect command to log into our SFTP server and update the files.teamkomin.com website... I'm not posting that here though as it contains security sensitive information.
Using this method, all members work on the ROM as though it were on the phone... This script packages it. No need to package or unpackage the entire thing.
Click to expand...
Click to collapse
ok cool. does this actually repack and zip align the APKs though? this looks like it just takes care of the overall ROM zip structure, not the APKs within..? maybe your script could call mine.. if there was a vbs parser for linux
omniwolf said:
ok, sounds like a good idea. i'm not actually a ROM developer, so i don't know the ins and outs of the various files. any hints on which files i exclude for various languages? just having a vague look around i see in framework-res.apk there's some raw-ar, raw-cs, raw-en-GB folders, are these the ones you're saying i can strip out?
this will obviously be a lot easier if i can do it programmatically, do you know the rules?
ok cool, added it in and uploaded 1.4.3. thanks dude.
ok cool. does this actually repack and zip align the APKs though? this looks like it just takes care of the overall ROM zip structure, not the APKs within..? maybe your script could call mine.. if there was a vbs parser for linux
Click to expand...
Click to collapse
We keep the APKs on the server for ease of use. It makes it easier to reference a single file for testing that way.
http://www.jsware.net/jsware/vblinux.php5
vbscript on linux with wine!
Got error on line 118 - WshShell.Run
Anything else shall I edit apart of 4 paths? I have 64-bit OS if that matters.
I just realized how much easier this would be on linux...
Code:
#! /bin/bash
OutDir=~/Desktop/newRom
InDir=~/Desktop/myRom
zipAlign=/home/adam/code/android-sdk-linux_x86/tools/zipalign
TempDIr=~/Desktop/TempDir
FIFO=~/Desktop/temp1234
realign="apk dll whatever files"
#set things up
rm -Rf "$OutDir"
mkdir "$OutDir"
rm "$FIFO"
mkfifo "$FIFO"
#Move to dir and start script
cd InDir
#Spawn another process to write to the fifo object
find `pwd`>"$FIFO" &
#read each line in the fifo
while read line
do
#get each object extension in $realign variable
for x in $realign
do
#test if the extension matches the realignment
if [ $x = ${line#*.} ]; then
#make the path in case it does not exist, could be optimized
touch "$line"
#meh... this would be the command ish...
"$zipAlign" "$line" "$temp/$line"
else
mv "$line" "$temp/$line"
fi
done
done <$FIFO
#this just removes the redundant filesystem created...
#/home/adam/desktop/out/home/adam/desktop/myrom
rm -Rf "$OutDir"
mkdir "$OutDir"
mv "$/TempDIr/$InDIr" "$OutDir"
Untested, should work with some realignment of the variables at the top.
mike1986. said:
Got error on line 118 - WshShell.Run
Anything else shall I edit apart of 4 paths? I have 64-bit OS if that matters.
Click to expand...
Click to collapse
i'd say it's a problem with your
sevenZipLoc
variable, it's the first place it gets used. my OS is 64bit too, so that shouldn't be a problem. what does your sevenZipLoc variable look like?
omniwolf said:
i'd say it's a problem with your
sevenZipLoc
variable, it's the first place it gets used. my OS is 64bit too, so that shouldn't be a problem. what does your sevenZipLoc variable look like?
Click to expand...
Click to collapse
sevenZipLoc = """C:\Program Files\7-Zip\7z.exe"""
EDIT:
It seems that I forgot to download "command version"...
Any way to add optimizing PNGs to this script as well?
williamfold said:
Any way to add optimizing PNGs to this script as well?
Click to expand...
Click to collapse
show me how to do this and i might be able to add it in..
Heres the link to the opensource OptiPNG program to optimize a PNG
http://optipng.sourceforge.net/
I hope it perfectly work
wow thanks bro, that's way i need to learn about it
For optimizing apks, aside from fixAllAPKs by omniwolf, I found another one.
Note: I have no responsibility for breaking your ROM, so backup first.
Rights: No rights reserved, you can do whatever you like.
The classes.dex files have significant amount of debug infos in it, striping out those can reduce file size and increase some performance. I test it with all /system/app/ and /system/framework/ files, the ROM runs snapier, especially when you launching apps. Stripe out those debug info doesn't hurt anything, they are usefull only for original developer and one who wants to mod it, but you can always keep a copy of the original one for modding and debugging purpose.
Note that this does not boost performance like increase CPU freq, but the theory is, since the file size is reduced, dex and dalvik-cache became smaller in size, occupies memories smaller, thus processing is faster, and saves a little battery life, you can think it as something like optipng does.
Note also, you don't need to specify 0 compression, dex will be decompressed to /data/dalvik-cache, just use fixAllAPKs for fixing files inside APK that should not be compressed, and 0 compression for file type like xml isn't really a good idea.
Don't use this for ICS Framework files yet, there are specific files will causes surprising bugs when recompiled, but I'm lazy to find it out why and what, so just don't do it.
For FixAllAPKs, original thread here, http://forum.xda-developers.com/showthread.php?t=1123463
or post #36 by carl1961 http://forum.xda-developers.com/showpost.php?p=21458549&postcount=36
==========================================================================================================
RemoveDebuggingInfo_v2.2:
API Level must be specified to get 100% compatibility, it seems not forward nor backward compatible.
Froyo = 8, GB = 10, ICS4.0 ~ 4.0.2 = 14, ICS 4.0.3 = 15
Added API Level chooser, default 15 (ICS 4.0.3)
Added more descriptions.
Correct typos.
==========================================================================================================
depricated...
RemoveDebuggingInfo_v2.1:
First, Thanks to all who corrects me.
fix typo for menu selection 6
fix path for pulling for adb to work without setting PATH env variable
fix pushing framework to wrong directory
update smali/baksmali to v1.3.2
update script to compile/decompile using api level 15
added menu selection of fixAllAPKs
Instructions: Important
The default config is for ICS 4.03 base ROM, if you are gonna use it for Gingerbread Base ROM, need to edit the file RemoveDebuggingInfo.bat, and change the -a 15 to -a 10 for API level 10, then just double click start.bat and follow the on screen instruction.
java -jar baksmali-1.3.2.jar -b -a 10 -o .\classes .\classes.dex
java -jar smali-1.3.2.jar -a 10 .\classes -o .\classes.dex
Click to expand...
Click to collapse
Using API level 10 for ICS and API level 15 for GB will not work, you phone will just hang or endless reboots.
Pushing framework will reset all your settings, so if you choose to push framework, do a factory reset instead and just re-install your user apps.
After pushing /system/app, you must reboot to recovery and wipe dalvik and cache, another way of pushing is boot to recovery, mount /system then push.
I have only tested on Gingerbread 2.08.401.1 base, have no idea for ICS, but it should work, as the latest smali/baksmali supports ICS.
If you experience glitches, do it from the beginning by using un-modified apk and jar.
How it works: it is just baksmali (decompile dex to smali code WITHOUT debugging info) and then smali (compile back to dex)
Requirements: java and htc sync usb driver.
==========================================================================================================
Depricated - too much error.
RemoveDebuggingInfo_v2:
Added another script for simpler operations, instead of dragging hundreds of APKs, it is self descriptive, can pull and push /system/app, /system/framework, optimizing all files for app and framework, and reboot to recovery.
Tested on v2.08.401.1 ROM, on all files /system/app, /system/framework, should work on other device and ROM too, but not sure, test it yourself!
==========================================================================================================
For /data/app/ user application files, modify it may not installed at all, re-sign it also not help, so just do it manually to test.
But for now, here is a way to do it manually, since /system partition will not grow and many spaces left, you can simply put some APP on this partition, and following are working on my ROM, some should have naming as com.a.b.c... whatever is the name installed on /data/app/ stripe out the -1 at the end. Just besure the APP is uninstalled before pushing to /system/app/
Below are what I tested.
AdobePhotoshopExpress.apk
BarcodeScanner.apk
com.evernote.skitch.apk
ESFileExplorer.apk
GoogleDocs.apk
GoogleGoggles.apk
GoogleTranslate.apk
GPSTest.apk
org.hermit.audalyzer.apk
For APKs that has lib folder, you can just extract it and put it on /system/lib/ then del the lib folder inside the apk archive, e.g. flashplayer, adobereader.
adb should be start only once after booting your PC, if you get issues, like adb always shows restarting and out of date, it is because the included adb.exe in htc sync is out of date, and you had installed android sdk with environmental variable set, to fix it, both must have same version, or simply delete one of them, and if you have path variable set, you can del the included adb.exe as well.
Thanks for this, I will be sure to use it
Sent from my HTC Sensation XE with Beats Audio Z715e using xda premium
I have 189 Apps in system/app .... is there a way to make it with all files!?
Jonny said:
Thanks for this, I will be sure to use it
Just out of interest, what program do you use for getting the smali code?
Click to expand...
Click to collapse
It is the one and only, baksmali.jar and smali.jar http://code.google.com/p/smali/
xtcislove said:
I have 189 Apps in system/app .... is there a way to make it with all files!?
Click to expand...
Click to collapse
Yes I know it is so much, but need to write a sohphisticated code, maybe if I have time, I'll try to make it more easier, a vbscript or cmd script, or a shell script in linux. And don't forget the framework files too.
mudhi said:
I test it with all /system/app/ and /system/framework/ files, the ROM runs snapier, especially when you launching apps.
Click to expand...
Click to collapse
It is really so. I have checked it up.
mudhi said:
It is the one and only, baksmali.jar and smali.jar http://code.google.com/p/smali/
Click to expand...
Click to collapse
Thank you mudhi
a little off topic here, Is there a way to change smali files into a readable code (let's say i want to use it with eclipse !!)
i have tried searching and i came across Dex2Jar and jd-gui !!
my question here is: is there a way to use smali files into Eclipse ??
Alfaifi said:
Thank you mudhi
a little off topic here, Is there a way to change smali files into a readable code (let's say i want to use it with eclipse !!)
i have tried searching and i came across Dex2Jar and jd-gui !!
my question here is: is there a way to use smali files into Eclipse ??
Click to expand...
Click to collapse
Yes, use dex2jar to jar archive file, then jd-gui to view the source, you can also use DJ-decompiler (commercial) to view and change code, but that's not really readable, and compile back is too hard, and also jbe, ce etc... but I came to a conclusion.
Use dex2jar to decompile dex and use jd-gui to view the source for understand logic, method etc... and just reference it to smali code, and if you get use to it, hacking app will be easier, perhaps more easier than viewing the source code, because hackiing involviing mostly on 0 to 1, true to false, jump to where ... and that is only adding or changing a single code in smali, e.g. logic if a == b then c, if you want to make it always c, then just if 0 == 0 then c, or just a simple jump etc...
@mudhi new smali/baksmali 1.3.2 is out
And is also possible to remove debugging info from jar files that are present in framework folder?
texture said:
And is also possible to remove debugging info from jar files that are present in framework folder?
Click to expand...
Click to collapse
I think you can just rename them to .apk and then back to .jar.
mike1986. said:
I think you can just rename them to .apk and then back to .jar.
Click to expand...
Click to collapse
No you dont need to, just put(or pull) all framework files (both apks and jars) and it will process them all automatically.
Btw i just ran this on InsertCoin 4.1.1 for all APPS and Framework except i changed a script a bit (added -mx0) so it compresses APKS with 0 compression.
And can tell you that phone definitively feels faster, boots faster, apps open faster, and there a bit more free RAM available now.
Thank you mudhi allot for this!
mike1986. said:
@mudhi new smali/baksmali 1.3.2 is out
Click to expand...
Click to collapse
ah... hehe thank you, supposed ICS 4.0.3 is supported. Thank you!
Need a little clarification ..
java -version
if errorlevel 1 goto javaerr
---------------------
C:\>java -version
'java' is not recognized as an internal or external command,
operable program or batch file.
---------------------
I installed java however still get an error ..
What is needed > to install ? Link Maybe ?
Also ... I found a small ops in the bat file ..
:javaerr
cls
echo Java is not found, please install java and rerun the script.
echo Hit anykey to quit
PAUSE
goto end < forgot this ?
Thanks ..
WarlockW said:
Need a little clarification ..
java -version
if errorlevel 1 goto javaerr
---------------------
C:\>java -version
'java' is not recognized as an internal or external command,
operable program or batch file.
---------------------
I installed java however still get an error ..
What is needed > to install ? Link Maybe ?
Also ... I found a small ops in the bat file ..
:javaerr
cls
echo Java is not found, please install java and rerun the script.
echo Hit anykey to quit
PAUSE
goto end < forgot this ?
Thanks ..
Click to expand...
Click to collapse
You need to set java variable, here's how-to:
http://java.com/en/download/help/path.xml
mudhi, You've got few errors in start.bat file. If you want to pull the apps to "app" folder, use this command "adb pull /system/app/ app". If you do cd app, It won't find the adb in the app folder and won't do nothing.
ivicask said:
No you dont need to, just put(or pull) all framework files (both apks and jars) and it will process them all automatically.
Btw i just ran this on InsertCoin 4.1.1 for all APPS and Framework except i changed a script a bit (added -mx0) so it compresses APKS with 0 compression.
And can tell you that phone definitively feels faster, boots faster, apps open faster, and there a bit more free RAM available now.
Thank you mudhi allot for this!
Click to expand...
Click to collapse
Before optimizing with this script, my apks are all fixed with the vbscript by omniwolf, it only compress files that should be compressed, the script fixAllAPKs.vbs can be used before or after this. Anyway, I'll add a decision to run the script.
mudhi said:
Before optimizing with this script, my apks are all fixed with the vbscript by omniwolf, it only compress files that should be compressed, the script fixAllAPKs.vbs can be used before or after this. Anyway, I'll add a decision to run the script.
Click to expand...
Click to collapse
Is there any problem with doing 0 compression on all files? I dont have space problems, and doesnt that make phone run faster as it doesnt need to decompress any data? Saves both CPU and RAM?
drms12 said:
mudhi, You've got few errors in start.bat file. If you want to pull the apps to "app" folder, use this command "adb pull /system/app/ app". If you do cd app, It won't find the adb in the app folder and won't do nothing.
Click to expand...
Click to collapse
Oh yes, I know where's the error, because I have android sdk installed and environmental PATH variable are set, you can fix it by just set the PATH variable with where the adb.exe exist.
Or just change the script with this
ullapp
cd app
../adb pull /system/app/
or
ullapp
adb pull /system/app/ app
same as pullframe
mudhi said:
Oh yes, I know where's the error, because I have android sdk installed and environmental PATH variable are set, you can fix it by just set the PATH variable with where the adb.exe exist.
Or just change the script with this
ullapp
cd app
../adb pull /system/app/
or
ullapp
adb pull /system/app/ app
same as pullframe
Click to expand...
Click to collapse
Yes
I think you forgot to update the download, It still ver2.
There is an error in script - the push command to upload files to framework uploads them to /system/app
ICS 4.0.3 - got bootloop just after lockscreen shows. Had to restore system.
Does the dsixda android kitchen work for making ICS roms, or is it too different from GB to use it?
Sent from my SAMSUNG-SGH-I727 using xda premium
Depends on what you want to do with it. For deodexing, do it by hand or you will be in for a world of hurt. Regarding the kernel, it would behoove you to just use romracer's kernel (or another init.d kernel) and overwrite boot.img in your kitchen folder. Lastly, you should really do the Edify by hand and make sure everything is as you would like it.
I basically only use the kitchen for zipalign and signing because I am lazy. Once you have played with the kitchen enough (and are comfortable with looking through the .sh scripts and Edify scripting) you will know how to do everything by hand (such as adding busybox, bash, etc.).
My 2 cents.
promiseofcake said:
Depends on what you want to do with it. For deodexing, do it by hand or you will be in for a world of hurt. Regarding the kernel, it would behoove you to just use romracer's kernel (or another init.d kernel) and overwrite boot.img in your kitchen folder. Lastly, you should really do the Edify by hand and make sure everything is as you would like it.
I basically only use the kitchen for zipalign and signing because I am lazy. Once you have played with the kitchen enough (and are comfortable with looking through the .sh scripts and Edify scripting) you will know how to do everything by hand (such as adding busybox, bash, etc.).
My 2 cents.
Click to expand...
Click to collapse
Ok that clears things up for me.
Here in this tutorial, I will show some facts about Deodex and Odex, then explain how to odex the framework of a ROM(which is pretty annoying, you'll find out). Credits goes to myself
This method should work on all Android devices.
------------------------------------------------------------------------------------------------------------
First of all, what is odex? Something you should know about classes.dex.
Odex stands for Optimized dex. I'm not gonna explain a lot because I'm not sure if I'm right. First of all, in typical apk files, when you open it with WinRAR or something like that, you can find a file called "classes.dex"(this type of apk is deodexed). This file is the key. It contains the core codes of the apk. However the other type of apk comes with an *.odex file and doesn't have classes.dex inside the apk file. This is odexed apk. There are 2 types of ROMs here, odexed and deodexed. Odexed ROMs' classes.dex are already out of the apk files, while deodexed ROMs' classes.dex are still in the apks. When Android executes an apk, it has to extract the classes.dex out and execute it. So when you flash an deodexed ROM, the first boot takes a long long time since the Android system needs to extract all the classes.dex into dalvik-cache(it shows "Optimizing apks" on the screen for 4.0 ROMs, shows boot animation on screen for 2.3 or below ROMs). However for the odexed ROMs, because the classes.dex are already out there, the system just grabs them and use them, without wasting time and storage space extracting classes.dex out.
Why odex framework?
It can boost your device a little by odexing your framework. Your phone can run more efficiently. Although it's a complicated process, but trust me, it's worth it.
What is so special about odexing framework files? What's the difference?
Odexing an app is very easy, and I believe everyone knows how to do it. But odexing framework is really annoying. Why? Because apps and more like stand-alone things, they are not a part of system. You delete it, nothing bad happens, your phone still boots, you just get endless FC if you delete the wrong one, or missing status bar, that's all. But framework files you cannot mess around. They are parts of the system. They have to match the system's codes precisely, without any error, even the order of files(keep this in mind, very important). So for every ROM, the framework initialize codes are different(same RUU or other ROM based ROMs count as its base ROM), and you must modify the odexing binary to make it odex for you properly, or you can sit and watch the beautiful bootloop.
What's the relationship between odexing apps and odexing framework?
Simple, but important. If you odexed apps, you cannot touch the framework. Framework always goes in the first place. If you wanna odex both, you must odex framework first. Or... "The Tragedy of App and Framework"...
So what do we have to keep in mind before we start?
Keep your mind clear, prepare a bag of ice in case you feel dizzy with the codes, and MAKE ENOUGH SPACE FOR FRAMEWORK ODEXING. I would prefer you remove a few useless apks in /system/app first to make more room in system partition. Failing odexing may brick your device forever! Nah just kidding it will only cause you to bootloop. No big deal. Also, it won't odex your framework-res.apk and always will not, so don't feel bad and do it again and again till your phone burn . Make sure your device is ROOTED and enable USB debug. You need Java Runtime Environment.
What tools do you need?
Notepad++ and a magical rar that contains all you need to success.
Let's get started.
------------------------------------------------------------------------------------------------------------
1. Use your file manager to find init.rc at the very root directory of your phone and copy it to SDCard for later code editing, or you simply adb pull it out and skip the coping step. (If you know how to compile boot.img it is even easier, just unpack boot in Android Kitchen, look for line "export BOOTClassPATH". I'm not gonna introduce that method since most people can't. Silly me, didn't I just intoduced that? XD)
2. Connect USB, set mode as disk drive so you can access your SDCard. Copy init.rc into your computer. Open it with notepad, and find where it says "export BOOTClassPATH", create a new file and copy line "export BOOTClassPATH" into the new file. For example:
Code:
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:/system/framework/HTCExtension.jar:/system/framework/com.htc.framework.jar:/system/framework/com.htc.android.pimlib.jar:/system/framework/com.htc.android.easopen.jar:/system/framework/com.scalado.util.ScaladoUtil.jar:/system/framework/com.orange.authentication.simcard.jar:/system/framework/android.supl.jar:/system/framework/com.ecrio.sip.jar
3. Open dexopter in the rar you downloaded with Notepad++. Find the lines that show the similar contents to the things after "export BOOTClassPATH". It is Line 21 to Line 35 on my laptop. Edit them according to the things you just copied out of init.rc. For example, if the first file is "X.jar", then you will have to edit the line into "dexopt-wrapper/system/framework/X.jar /system/framework/X.odex". Then repeat until you finish with all the files that are listed in the long list you copied out of init.rc. File order DOES MATTER. Use the bag of ice I told you to prepare eariler to make you sober if you feel dizzy with the codes. The lines may be more or less after you edited them, doesn't matter.
4. Copy "dexopter" and "dexopt-wrapper" into /system/bin and set the correct permissions. Make sure they have enough permission to change your system files. Restart your phone.
5. Go to CMD and lead it to where adb.exe is(included in the rar). Type these in order:
Code:
adb shell
su
cd system/framework
dexopter fr
Then the codes will run crazy in your cmd window... The odex process has begun!
6. If the odex process completed without error, you are half way there! Well it doesn't mean you have to stare at your screen during the process. It's about time we figure it out! The phone will automatically reboot once it's finished. If it doesn't and you are sure all are done, reboot manually.
7. If you can't boot properly, go back and check everything carefully. If you can, then open your file manager and copy the entire framework directory into your SDCard. You can still adb pull and skip the next coping step.
8. Mount SDCard. Go into framework directory on your computer. Open every file that has an odex file with it, delete the classes.dex inside. WinRAR is okay. The files may seem ridiculously small after you delete the classes.dex, but don't worry since classes.dex are already pulled out and turned into odex files.
9. Copy the whole framework folder into the folder where adb is at. Use adb to push all the files back into /system/framework.
Code:
adb root
adb remount
adb push framework /system/framework
adb shell
su
chmod /system/framework xxx (xxx is a permission code, depends on your ROM. They should be the same as the old deodexed framework files. Use Google to find out how to use the permission codes.)
10. After all the files are pushed in, reboot your phone.
11. If it still boots into the system, congratulations! You've successfully odexed your framework! If it doesn't, then go back and read everything carefully. The most common error occurs when you are editing the dexopter code. You will have to redo everything again.
Done! Everything is ready to go!
You can directly grab the files you've odexed and put it in your custom ROM(must be the same base), just don't forget the odex files.
------------------------------------------------------------------------------------------------------------
Okay, hmm, what to say now? Still, I would be glad if you donated me, but if you don't it's okay, just reply and hit thanks .
Oh almost forgot, the magical rar: http://d-h.st/tYi
------------------------------------------------------------------------------------------------------------
Big thanks to Scott, see him in #3. He explained why some files aren't odexed and provided a easier method(but they all get you dizzy )
Big thanks to JSLEnterprises, see him in #4. He provided a newer busybox for Scott's method.
If you can, send me a PM on how to odex apps.
Sent from my HTC One X using Tapatalk 2
BreatheHT said:
Here in this tutorial, I will show some facts about Deodex and Odex, then explain how to odex the framework of a ROM(which is pretty annoying, you'll find out). Credits goes to myself
Also, it won't odex your framework-res.apk and always will not, so don't feel bad and do it again and again till your phone burn . Make sure your device is ROOTED and enable USB debug. You need Java Runtime Environment.
Click to expand...
Click to collapse
Good write up. Other files that wont "re-odex" are com.htc.resources.apk, com.htc.videowidget.res.apk, com.htc.weather.res.apk and framework-htc-res.apk.
The reason? The files dont have .dex files because there is no code in them. These files just carrier resources like images (for those that didint know).
The .dex files are the actual smali code that devs mod to make the ROM do crazy things
Also, an easier method can be found here: http://themikmik.com/showthread.php?12988-Tool-App-Dexo-the-Universal-Odex-Utility
It does it all and pulls the bootclass for you. And it also does /system/app/ in one simple shot.
Also, one last thing... You can just as easily pull the files back to the PC using the ADB Pull command...
Code:
adb pull /system/app ./app
adb pull /system/framework/ ./framework
EDIT: And another simple method to get your bootclass is do another ADB Pull
Code:
add pull init.rc
I find the adb pull method quicker and more simple...
theking_13 said:
If you can, send me a PM on how to odex apps.
Sent from my HTC One X using Tapatalk 2
Click to expand...
Click to collapse
You can use the method I just explained or if you want to try the framework manually then do apps seperately then you can use this: http://forum.xda-developers.com/showthread.php?t=1514576
I use that app to re-odex updated files in the ROM. For example... If Gmail updates (which it just did) I would remove the old gmail files from system/app/ and put the new one in and run that program then pull the files.
-Scott
If anyone finds this to be too much work... dont worry... it only unpacks the classes.dex once. It will only need to unpack a dex if original file has changed (changed entries need to propogate). That's why all the consecutive boots are back to a 'normal' span of time.
re-odexing your roms IS recommended if either A) you're anal-retentive/have OCD or B) propogation ("Android is Upgrading...") happens every time you reboot your device (it happens sometimes)
If you're going to use the tool scrosler linked to, replace the busybox binary with the one inside the attatched zip (this is busybox 1.20.1). The one that come with the tool is pretty dated.
:good:
Update: Busybox 1.20.2 has been released (though not compiled for android use yet)
Great stuff guys.
scrosler said:
Good write up. Other files that wont "re-odex" are com.htc.resources.apk, com.htc.videowidget.res.apk, com.htc.weather.res.apk and framework-htc-res.apk.
The reason? The files dont have .dex files because there is no code in them. These files just carrier resources like images (for those that didint know).
The .dex files are the actual smali code that devs mod to make the ROM do crazy things
Also, an easier method can be found here: http://themikmik.com/showthread.php?12988-Tool-App-Dexo-the-Universal-Odex-Utility
It does it all and pulls the bootclass for you. And it also does /system/app/ in one simple shot.
Also, one last thing... You can just as easily pull the files back to the PC using the ADB Pull command...
Code:
adb pull /system/app ./app
adb pull /system/framework/ ./framework
EDIT: And another simple method to get your bootclass is do another ADB Pull
Code:
add pull init.rc
I find the adb pull method quicker and more simple...
You can use the method I just explained or if you want to try the framework manually then do apps seperately then you can use this: http://forum.xda-developers.com/showthread.php?t=1514576
I use that app to re-odex updated files in the ROM. For example... If Gmail updates (which it just did) I would remove the old gmail files from system/app/ and put the new one in and run that program then pull the files.
-Scott
Click to expand...
Click to collapse
hehe yep I know the adb pull command, I thought about it and I didn't put it in...
theking_13 said:
If you can, send me a PM on how to odex apps.
Sent from my HTC One X using Tapatalk 2
Click to expand...
Click to collapse
You confused bro?
Thanks. Even though I won't ever be doing this, it's good to know what's going on.
This is awesome. Thanks so much for this. I wanted to know how to odex and deodex roms.
Sent from my HTC One XL using xda app-developers app
scrosler said:
Good write up. Other files that wont "re-odex" are com.htc.resources.apk, com.htc.videowidget.res.apk, com.htc.weather.res.apk and framework-htc-res.apk.
The reason? The files dont have .dex files because there is no code in them. These files just carrier resources like images (for those that didint know).
The .dex files are the actual smali code that devs mod to make the ROM do crazy things
Also, an easier method can be found here: http://themikmik.com/showthread.php?12988-Tool-App-Dexo-the-Universal-Odex-Utility
It does it all and pulls the bootclass for you. And it also does /system/app/ in one simple shot.
Also, one last thing... You can just as easily pull the files back to the PC using the ADB Pull command...
Code:
adb pull /system/app ./app
adb pull /system/framework/ ./framework
EDIT: And another simple method to get your bootclass is do another ADB Pull
Code:
add pull init.rc
I find the adb pull method quicker and more simple...
You can use the method I just explained or if you want to try the framework manually then do apps seperately then you can use this: http://forum.xda-developers.com/showthread.php?t=1514576
I use that app to re-odex updated files in the ROM. For example... If Gmail updates (which it just did) I would remove the old gmail files from system/app/ and put the new one in and run that program then pull the files.
-Scott
Click to expand...
Click to collapse
Is there also a tool to deodex roms?
Sent from my HTC One XL using xda app-developers app
SkizzMcNizz said:
Is there also a tool to deodex roms?
Sent from my HTC One XL using xda app-developers app
Click to expand...
Click to collapse
Like Scott posted?
Basically that is the steps right there..you are doing the apk in the system/app and framework.
That link provides a tool which when done properly will run on the de-odexed stock Rom and odex it...
Good luck with that...it's a nightmare...haha..
SkizzMcNizz said:
Is there also a tool to deodex roms?
Sent from my HTC One XL using xda app-developers app
Click to expand...
Click to collapse
Yep Android Kitchen can do it.
Hopefully this will help to see more odex ROMs
This is the first phone I've had where developers strive to odex their roms
Something to get used to
Sent from my HTC One X using Tapatalk 2
superchilpil said:
This is the first phone I've had where developers strive to odex their roms
Something to get used to
Sent from my HTC One X using Tapatalk 2
Click to expand...
Click to collapse
Most official ROMs are odexed.
BreatheHT said:
Most official ROMs are odexed.
Click to expand...
Click to collapse
Quite the opposite where I come from
Although I came from a different carrier so this side of the forums is different
Sent from my HTC One X using Tapatalk 2
superchilpil said:
Quite the opposite where I come from
Although I came from a different carrier so this side of the forums is different
Sent from my HTC One X using Tapatalk 2
Click to expand...
Click to collapse
Nah carrier doesn't matter.
SkizzMcNizz said:
Is there also a tool to deodex roms?
Sent from my HTC One XL using xda app-developers app
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1208320
(you'll have to update the versions included in the zip as this thread is dated - 2011)
Note: the API level for 4.0.3/4.0.4 (what our HOX's run) is '15'.
you can also use DSIXDA's kitchen which can be used to batch deodex apk's after you set the api level
(it's defaulted to '10'... which was Gingerbread -> 2.3.3-2.3.7)
Full list of API levels for their specific Android versions
BreatheHT said:
hehe yep I know the adb pull command, I thought about it and I didn't put it in...
Click to expand...
Click to collapse
Yeah, I like to do it better that way. Dont have to move my hands from the keyboard and mouse. Makes you more efficient :good:
BreatheHT said:
Most official ROMs are odexed.
Click to expand...
Click to collapse
I think all?
superchilpil said:
Quite the opposite where I come from
Although I came from a different carrier so this side of the forums is different
Sent from my HTC One X using Tapatalk 2
Click to expand...
Click to collapse
Carrier is irrelevant. Most people dont know how to work with ODEX files so they go with de-odex. Its mroe challanging but provides a better experience.
techlogik said:
Like Scott posted?
Basically that is the steps right there..you are doing the apk in the system/app and framework.
That link provides a tool which when done properly will run on the de-odexed stock Rom and odex it...
Good luck with that...it's a nightmare...haha..
Click to expand...
Click to collapse
No he is asking to go the other way from odex to de-odex.
BreatheHT said:
Yep Android Kitchen can do it.
Click to expand...
Click to collapse
JSLEnterprises said:
http://forum.xda-developers.com/showthread.php?t=1208320
(you'll have to update the versions included in the zip as this thread is dated - 2011)
Note: the API level for 4.0.3/4.0.4 (what our HOX's run) is '15'.
you can also use DSIXDA's kitchen which can be used to batch deodex apk's after you set the api level
(it's defaulted to '10'... which was Gingerbread -> 2.3.3-2.3.7)
Full list of API levels for their specific Android versions
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Yep, I love that script. I was the one that sent him the mnt point file for the HOX :highfive:
I am going to talk to him about bringing in "official" support for the Asus TF300T. I got the boot.img fiugred out this morning! Woot. **** is about to get real with the Asus!
superchilpil said:
This is the first phone I've had where developers strive to odex their roms
Something to get used to
Sent from my HTC One X using Tapatalk 2
Click to expand...
Click to collapse
its a good final touch when cook done with smali tweaks.
another benefit is sorta kang-protection
Subject says it all. Just enabled init.d in stock and looking to see what scripts people are using and why?
And just to clarify, I'm already using "01permissive" and "08setperm", essentially the base scripts put in place Ryuinferno's init.sh file.