[Complete Guide] What is Odex and Deodex ROM? - Galaxy S Advance I9070 General

What is an ODEX file?
In Android file system, applications come in packages with the extension .apk. These application packages, or APKs 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.
What is an DEODEX file?
Deodexing is basically repackaging of these APKs in a certain way, such that they are reassembled into classes.dex files. By doing that, all pieces of an application package are put together back in one place, thus eliminating the worry of a modified APK conflicting with some separate odexed parts.
So, Deodexed ROMs (or APKs) have all their application packages put back together in one place, allowing for easy modification such as theming. Since no pieces of code are coming from any external location, custom ROMs or APKs are always deodexed to ensure integrity.
How this works?
For the majority noobs amongst us, Android OS uses a Java-based virtual machine called the Dalvik Virtual Machine. A deodexed or .dex file contains the cache used by this virtual machine (referred to as Dalvik-cache) for a program, and it is stored inside the APK. An .odex file, on the other hand, is an optimized version of this same .dex file that is stored next to the APK as opposed to inside it. Android applies this technique by default to all the system applications.
When an Android-based system is booting, the davlik cache for the Davlik VM is built using these .odex files, allowing the OS to learn in advance what applications will be loaded, and thus speeds up the booting process.
By deodexing these APKs, a developer actually puts the .odex files back inside their respective APK packages. Since all code is now contained within the APK itself, it becomes possible to modify any application package without conflicting with the operating system’s execution environment.
Advanteges & Disadvantages
The advantage of deodexing is in modification possibilities. This is most widely used in custom ROMs and themes. A developer building a custom ROM would almost always choose to deodex the ROM package first, since that would not only allow him to modify various APKs, but also leave room for post-install theming.
On the other hand, since the .odex files were supposed to quickly build the dalvik cache, removing them would mean longer initial boot times. However, this is true only for the first ever boot after deodexing, since the cache would still get built over time as applications are used. Longer boot times may only be seen again if the dalvik cache is wiped for some reason.
Note:Themes for android come in APKs too, and if you want to modify any of those, you should always choose a dedoexed custom ROM.

[Guide] What is Zipalign and how to make Apps zipaligned
What is Zipalign?
Zipalign is an archive alignment tool introduced first time with 1.6 Android SDK (Software Development Kit). It optimizes the way an Android application package (APK) is packaged. Doing so enables the Android operating system to interact with the application more efficiently, and hence has the potential to make the application and overall the whole system much faster. Execution time is minimized for zipaligned applications, resulting is lesser amount of RAM consumption when running the APK.
How does it exact work?
In an Android operating environment, data files stored in each application package are accessed by multiple processes, for example, the installer will read the data manifest to determine the associated permissions; the system server can read these resources for multiple reasons, like displaying notifications; the Home application, for example, will read resources to get the application’s name and icon. Since Android is based on a a true multi-tasking operating infrastructure, these files are continually and repeatedly accessed. Finally, but not least, the application itself reads the manifest data.
As Android is Linux-based, memory-mapping plays a key role in efficient handling of processes. Essentially, the optimal alignment for the Android OS’ resource-handling code is 4-byte boundaries. What this means is that, if APKs are memory-mapped to 4-byte boundaries, and aligned accordingly, the OS will not need to ‘read through’ the whole application package to get to the desired data manifest. Every system process will know in advance where to look for it’s desired resources, and hence will execute much smoother and faster.
Summing it up, zipaligning an APK results in all uncompressed data within the package to be aligned on 4-byte boundaries, allowing all portions to be accessed directly with the memory-map. RAM consumption is lowered while execution because the querying code doesn’t have to read through the entire application package.
Disavantages of unaligned APKs
Quite understandably, situation would be reserved for unaligned application packages. Resource reading would be slow and memory usage would be on the higher end of the spectrum. It would also depend on how many unaligned applications are present. For example, if less number of applications with an unaligned home application, you’d see slower application launch times. This is the best case scenario. For a worst case scenario, having a number of unaligned applications will result in the system repeatedly starting and killing processes, struggling with lags and huge battery drain.
How to make APKs zipaligned?
As mentioned earlier, the zipalign tool became a part of Android SDK from 1.6 onwards. It can be found under the ‘tools’ folder of the SDK. To use it, simply run the command:
zipalign [-f] [-v] <alignment> infile.apk outfile.apk
Click to expand...
Click to collapse
...where infile.apk is the source file, and outfile.apk is the output file.
You can also verify the alignment of an APK file using the following command:
zipalign -c -v <alignment> existing.apk
Click to expand...
Click to collapse
...where existing.apk can be any application package that you need to get verified. Also, the <alignment> tag in both the commands needs to be an integral value (otherwise the command will return invalid). This value, although can be any integer, MUST always be 4, which would provide 32-bit alignment. Any other value and it will effectively do nothing.
Finally, for the flags used in these commands,
-f - overwrites existing outfile.zip
-v - will give verbose output
-c - will confirm the alignment of a given file
Click to expand...
Click to collapse
CAUTION: Zipalign operation must only be performed after you have signed the APK file with your private key. If zipaligned before signing, the signing procedure will disturb the alignment. Same holds true for any other alteration, addition or removal to the APK file. Any change after running zipalign will undo the alignment.
Source: addictivetips

[GUIDE] How to Deodex Jelly Bean firmware (I9070) - credits must go to anantttt
[How-To] Re-Odex a Rom - credits must go to TearsDontFalls -this guide is for S3, but you have Google to find what you need ... if you really need.
[ODEX][SCRIPT/TOOL] Odexer Tool 1.2 (03-28-2014)(MM-dd-yyyy)
Update 08.10.2014
Click to expand...
Click to collapse
[SCRIPT TO ODEX] Universal Odex Script Version 6.3.1 (11-03-2013)
Credits & Thanks for this tool:
MatrixDJ96
Click to expand...
Click to collapse

I think you just must create 1 thread titled "About Android" or someting like that
BTW it is good to know that:thumbup::thumbup:
Sent from my GT-I9070 using xda app-developers app

This materials are not created by me, I just searched and read carefully over the WWW in an attempt to bring as much informations to our forum S. Advance.
Only this was my job, along with the desire to know the phone held.
In my opinion, one thread with all the information is difficult to manage, because of that i'm so reluctant in what concerns for easy finding by members.

Make a Guide on how to (Re)Odex a Deodexed ROM if possible...
Sent from my GT-I9070 using xda app-developers app

Flash stock ROM?

R_a_z_v_a_n said:
Flash stock ROM?
Click to expand...
Click to collapse
Hahahaha.. but I wasn't Joking.. people say that its always better Re-Odex a Deoxed app after editing it

Understand now. Let me do some research and read what to do in that sense ...

Sami Kabir said:
Make a Guide on how to (Re)Odex a Deodexed ROM if possible...
Click to expand...
Click to collapse
Make it very short then.
Odex Me
(Post useful? Hit the Thanks button etc.)

Odex and Deodex
Hi,
I am a beginner in the android world and i have been trying to understand the android terms in detail. but i am still confused over the ODEX and DEODEX terms. I read you post but it still needs some more explanation of few things mentioned below.
Where is the .ODEX file stored in case of an ODEXED Rom?
Does the Dalvik Cache builds up in case the ROM in Deodexed. If yes then from where it fetches the required information?
Your post says that boot speed is increased in case of both the ODEX & DEODEX ROM after the first Boot. Then what is the exact difference between the two ROMS?
Does Dalvik Cache & DalviK VM independent whether the ROM is ODEX or DEODEX?
Presently my phone is ODEX (Stock ROM), once i DEODEX the ROM can i still install .APK files from Google Play or any other source?
Is tools which makes an APK ODEX or DEODEX part of the android operating system or should we make an APK Odexed or Deodexed using a laptop?
Please help me with the above questions.
R_a_z_v_a_n said:
What is an ODEX file?
In Android file system, applications come in packages with the extension .apk. These application packages, or APKs 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.
What is an DEODEX file?
Deodexing is basically repackaging of these APKs in a certain way, such that they are reassembled into classes.dex files. By doing that, all pieces of an application package are put together back in one place, thus eliminating the worry of a modified APK conflicting with some separate odexed parts.
So, Deodexed ROMs (or APKs) have all their application packages put back together in one place, allowing for easy modification such as theming. Since no pieces of code are coming from any external location, custom ROMs or APKs are always deodexed to ensure integrity.
How this works?
For the majority noobs amongst us, Android OS uses a Java-based virtual machine called the Dalvik Virtual Machine. A deodexed or .dex file contains the cache used by this virtual machine (referred to as Dalvik-cache) for a program, and it is stored inside the APK. An .odex file, on the other hand, is an optimized version of this same .dex file that is stored next to the APK as opposed to inside it. Android applies this technique by default to all the system applications.
When an Android-based system is booting, the davlik cache for the Davlik VM is built using these .odex files, allowing the OS to learn in advance what applications will be loaded, and thus speeds up the booting process.
By deodexing these APKs, a developer actually puts the .odex files back inside their respective APK packages. Since all code is now contained within the APK itself, it becomes possible to modify any application package without conflicting with the operating system’s execution environment.
Advanteges & Disadvantages
The advantage of deodexing is in modification possibilities. This is most widely used in custom ROMs and themes. A developer building a custom ROM would almost always choose to deodex the ROM package first, since that would not only allow him to modify various APKs, but also leave room for post-install theming.
On the other hand, since the .odex files were supposed to quickly build the dalvik cache, removing them would mean longer initial boot times. However, this is true only for the first ever boot after deodexing, since the cache would still get built over time as applications are used. Longer boot times may only be seen again if the dalvik cache is wiped for some reason.
Note:Themes for android come in APKs too, and if you want to modify any of those, you should always choose a dedoexed custom ROM.
Click to expand...
Click to collapse

fredrickaein said:
1.Where is the .ODEX file stored in case of an ODEXED Rom?
2.Does the Dalvik Cache builds up in case the ROM in Deodexed. If yes then from where it fetches the required information?
3.Your post says that boot speed is increased in case of both the ODEX & DEODEX ROM after the first Boot. Then what is the exact difference between the two ROMS?
4.Does Dalvik Cache & DalviK VM independent whether the ROM is ODEX or DEODEX?
5.Presently my phone is ODEX (Stock ROM), once i DEODEX the ROM can i still install .APK files from Google Play or any other source?
6.Is tools which makes an APK ODEX or DEODEX part of the android operating system or should we make an APK Odexed or Deodexed using a laptop?
Click to expand...
Click to collapse
Some answers, I numbered your questions to be more easily tracked
1. In your /system
2. Android's Dalvik goes through every apk's and extracts the dex file from it. It places the dex files in the cache folder - located at /data/dalvik-cache. This is the directory that gets cleared when you clear the dalvik cache in your custom recovery like CWM or TWRP.
3. The difference is that deodexed ROMs are lighter and allow modifications but odexed ROMs load faster. ROMs come with Zipalign at boot that make a deodexed ROM load as fast as an odexed ROM.
4. I dont know the answer of this ... sorry.
5. Of course you can, is no reason to worry about.
6. You need android-sdk installed in your computer/laptop, busybox on the phone, xUltimate and some knowledge about whole process.

Thanks a few more on odexed and deodexed ROM
Hi,
Many thanks for your prompt reply. But please bare with me as i am going to ask more questions
Firstly let me ask you some more queries related to the earlier questions
1 Which folder in my ROM. I have root access, so i would like to view the files.
2 got it. saw the directory where the delvik cache is stored, but in case of a deodexed rom does this happen? i mean does the system store the dalvik cache by going through the apk if the ROM is deodexed. in other words does dalvik cache exist for deodexed ROM?
3 why is the deodexed ROM lighter? is it because it stores the app info at one place?
4. actually the question is same as no 2 above, Will i see the delvik-cache folder anymore if i deodex my ROM? if no then does the zipalign provides necessary data for the dalvik VM?
5.Ok i understood this
6. the process you are talking about is how to deodex my ROM. So i guess once i try to deodex my ROM the process will convert all the odexed app in my phone to deodexed. and henceforth all the appliccation that i install will be installed as a deodexed app. am i right in my guess?
Now some more questions please
7. is the only difference between them is the fact that odexed rom stores the app in two places and deodexed rom stores as a single apk?
8. what exactly is the .ODEX dex file. Is it a full copy of the apk or only a part of the apk. i guess it is this .ODEX file that makes the odexed rom heavy while the deodexed rom doesnt contain a .ODEX file which makes it lighter
R_a_z_v_a_n said:
Some answers, I numbered your questions to be more easily tracked
1. In your /system
2. Android's Dalvik goes through every apk's and extracts the dex file from it. It places the dex files in the cache folder - located at /data/dalvik-cache. This is the directory that gets cleared when you clear the dalvik cache in your custom recovery like CWM or TWRP.
3. The difference is that deodexed ROMs are lighter and allow modifications but odexed ROMs load faster. ROMs come with Zipalign at boot that make a deodexed ROM load as fast as an odexed ROM.
4. I dont know the answer of this ... sorry.
5. Of course you can, is no reason to worry about.
6. You need android-sdk installed in your computer/laptop, busybox on the phone, xUltimate and some knowledge about whole process.
Click to expand...
Click to collapse

My friend,
You ask too many questions and I do not think going somewhere after you have the answers.
So, lets start with ...
1.There is two place: I tell you in system/root ... search for directors -> data/app or system/app
2 Of course. Because of this the first start of a deodexed ROM is slower.
3 ... is it because it stores the app info at one place? I dont know for sure, but is one of the explanation. Lighter can also mean that the apk can be modified by Themers much easier without any risk.
4. Yes will see the folder, i just tell where is located from my phone when i answered before. And i have my ROM deodexed and zipalign
5....
6. You are right.
7. Yes, and much easier to theme without risks
8. I guess is correct, dont know much about that

present hipirch
Dear Razvan,
Thanks for the help. I am very curious in nature, that why i bothered you so much.
Now please a last suggestion from you.
Shall i Deodex my Samsung Stock ROM? or go for already deodexed Pure Vanila or Jelly Bean LQB / SlimJB - Shaaan (Your Rom). please Suggest.
And also based on your experience, which Custom ROM you prefer for Galaxy S Advance (Just your Opinion )
R_a_z_v_a_n said:
My friend,
You ask too many questions and I do not think going somewhere after you have the answers.
So, lets start with ...
1.There is two place: I tell you in system/root ... search for directors -> data/app or system/app
2 Of course. Because of this the first start of a deodexed ROM is slower.
3 ... is it because it stores the app info at one place? I dont know for sure, but is one of the explanation. Lighter can also mean that the apk can be modified by Themers much easier without any risk.
4. Yes will see the folder, i just tell where is located from my phone when i answered before. And i have my ROM deodexed and zipalign
5....
6. You are right.
7. Yes, and much easier to theme without risks
8. I guess is correct, dont know much about that
Click to expand...
Click to collapse

Do not you worry I did not mind. :highfive:
You can put a deodexed ROM, but only if you want to apply some themes or customization, otherwise there is no reason to do so.
Frankly, in terms of what ROM to install, I can not give any advice, because besides his SlimJB Shaaan, i did not try any custom ROM, but i'm waiting, in silence , Cyanogen ROM stable and then i can make a choice.
Good luck

Yeah, I am also waiting for a stable 10.1 of cynogen. But how is the rom that you are using? How stable is it? I am also planing to try pure vanila till we have a stable release of cynogen. Anyways many thanks for the help.
R_a_z_v_a_n said:
Do not you worry I did not mind. :highfive:
You can put a deodexed ROM, but only if you want to apply some themes or customization, otherwise there is no reason to do so.
Frankly, in terms of what ROM to install, I can not give any advice, because besides his SlimJB Shaaan, i did not try any custom ROM, but i'm waiting, in silence , Cyanogen ROM stable and then i can make a choice.
Good luck
Click to expand...
Click to collapse

For the moment i'm using LQB Serbia, deodexed, zipaligned and debloated with CoCore 6.x kernel and i'm SOOO happy .... but we are OFF TOPIC here, thanks for understanding me.

Just a question. I am now on stock odex DXLSE with speedmod kernel. Can I flash on cwm the deodexed version of the same rom without wiping the data and without losing all of my files? Thanks.

JB? Rooted?
Its necessary...
Sent from my GT-I9070 using xda premium

Related

Auto-Deodexer 2.3 [SCRIPT] [FROYO SUPPORT] [Devs Only]

Hey guys, so this script de-odexe's a rom's apks and jar's.
Many thanks to ofcourse JesusFreke who created this method and the way to do it. Also to coolbho for his apkopt script from which i learnt certain techniques of batch programming. This is crzyruski script updated with jesus freke's latest smali/baksmali update ver 1.2.3
It incorporates detecting the bootclasspath of the odex instead of the user specifying it. For non standard odex however a specific bootclass path must be defined. For example:
According to Jr33 for rosie deodexing u have to add class paths com.htc.framework.jar. Thank him for the new Sense bootclasspaths
For those who dont know, this essentially uses jf's method of baksmali'ing the odex file into smali files, and then recreating the classes.dex file and packaging it into the apk hence disregarding the need for the odex.
*New Menu added
*Ability to specify custom bootclasspath (eg for sense ui)
*Added a java check at the beginning
*Added 1.2.3 smali/baksmali with froyo support(thank jf ofcourse )
*Modified it so if an error is encountered during deodexing, it leaves that file behind so once done you know what files encountered errors
*Added Ignore Mode
*Removed zipalign
*If apk doesnt have corresponding odex, it moves it to deodexed_APK instead of user manually moving it
*Added compression level option
*You can monitor the status of ignore mode / compression level right above the main menu
DISCLAIMER:
Its a batch file so it'll only work on windows.
Convince farmatito to bring this to linux
Thanks
So I checked this out and all ...
It's only apk's, right?
I only glanced but I didn't see anything in there for framework, etc.
If I'm right, then perhaps .. you should just say it de-odex's a ROM's apk's instead of the entire ROM.
~enom~
enomther said:
So I checked this out and all ...
It's only apk's, right?
I only glanced but I didn't see anything in there for framework, etc.
If I'm right, then perhaps .. you should just say it de-odex's a ROM's apk's instead of the entire ROM.
~enom~
Click to expand...
Click to collapse
Oh, yea so it takes the apk and odex and creates the classes.dex and repackages into the apk so u only need the apk. Ok, ill change the post a bit also yes, it doesnt do frameworks cuz i dont think they have odex's and the jar's do but i dunno of a method to do tht
Daneshm90 said:
Oh, yea so it takes the apk and odex and creates the classes.dex and repackages into the apk so u only need the apk. Ok, ill change the post a bit also yes, it doesnt do frameworks cuz i dont think they have odex's and the jar's do but i dunno of a method to do tht
Click to expand...
Click to collapse
Yea ... the jar's have dex's too and can be odex-d and can also be un-odex-d. I personally have never been able to successfully de-odex a fully odex'd framework (but I haven't tried hard enough either ). The main difference is once they are de-odex'd ... you insert the classes.dex into the jar and no re-signing required (as they aren't signed).
Either way, nice script mate. Good Job!
~enom~
enomther said:
Yea ... the jar's have dex's too and can be odex-d and can also be un-odex-d. I personally have never been able to successfully de-odex a fully odex'd framework (but I haven't tried hard enough either ). The main difference is once they are de-odex'd ... you insert the classes.dex into the jar and no re-signing required (as they aren't signed).
Either way, nice script mate. Good Job!
~enom~
Click to expand...
Click to collapse
Ah sweet, something i shall incorporate in the script later on. thanx
so will this script allow you to take an app from say a cliq dump and allow it to run on any android device?
Will this allow you to grab the MyFaves from a TMO rom and de-odex it and install?
Joe333x said:
so will this script allow you to take an app from say a cliq dump and allow it to run on any android device?
Click to expand...
Click to collapse
Emm...no im 99.99% sure it doesnt help tht way. I know that odex's cause customization problems in roms....there are other factors im sure
mrandroid said:
Will this allow you to grab the MyFaves from a TMO rom and de-odex it and install?
Click to expand...
Click to collapse
MyFaves == No Go ... it requires some other form of trickery ... I'm not sure what exactly ... as I did de-odex it and it would not work properly on test-key ROM's like CM, etc.
... So it requires more than a simple de-odex.
~enom~
does your phone need to be connected? I noticed some ADB commands in the script
Daneshm90 said:
Hey guys, so this script de-odexe's a rom's apks.
Many thanks to ofcourse JesusFreke who created this method and the way to do it. Also to coolbho for his apkopt script from which i learnt certain techniques of batch programming
For those who dont know, this essentially uses jf's method of baksmali'ing the odex file into smali files, and then recreating the classes.dex file and packaging it into the apk hence disregarding the need for the odex.
Oh also make sure to place only apk's that have their corresponding odex's. Dont place only apk's !!!!!
Instructions:[WINDOWS ONLY & Phone Must stay connected with adb WORKING]
1. Download http://www.mediafire.com/?mwownkhzm4m
2. Extract to a folder
3. Place all your rom's apk's which have odex's attached to them into that folder
4. Run deoall
5. Copy all the apk's from the deodexed folder into ur corresponding rom app folder
Thanks
Upcoming:
Seperate Framework & apps folder
De-odex framework apk's and jar's (thanx for the tip enomther )
Click to expand...
Click to collapse
So the apk after that has the DEX built in or is dexopt still needed?
wesgarner said:
So the apk after that has the DEX built in or is dexopt still needed?
Click to expand...
Click to collapse
>.<.......................
kingklick said:
>.<.......................
Click to expand...
Click to collapse
Hey I am just double checking
If you're having problems de-odexing the framework is because there's a particular order to it.
If you look at your bootclasspath you'll see the framework files necessary to boot the android system, the rest (whatever's not in there) can be dexopted in any order.
If you're trying to de-odex the framework, you're going to have to backtrace yourself.
Personally, I do:
for i in /system/app/*.apk
unodex
for j in /system/framework/nonCoreJar1.jar /system/framework/nonCoreJar2.jar /system/framework/...nonCoreJarN.jar
unodex
for k in /system/framework/bootClassPathJarN.jar /system/framework/bootClassPathJarN-1.jar /system/framework/...bootClassPathJarN-y.jar
unodex
it requires a couple of reboots along the way to deal with any created dalvik-cache so that it doesn't interfere with the next needed classes.dex
the only turn-off was that it requires a running system to do it (it's not that big of a problem, but porting and then flashing starts getting old after a while).
Has that changed?
Does OP mean you can take the apks, toss them into a folder, and then do it from the computer without the phone?
---edit---
shoot me for not reading.
Daneshm90 said:
Instructions:[WINDOWS ONLY & Phone Must stay connected with adb WORKING]
Click to expand...
Click to collapse
jubeh said:
If you're having problems de-odexing the framework is because there's a particular order to it.
If you look at your bootclasspath you'll see the framework files necessary to boot the android system, the rest (whatever's not in there) can be dexopted in any order.
If you're trying to de-odex the framework, you're going to have to backtrace yourself.
Personally, I do:
for i in /system/app/*.apk
unodex
for j in /system/framework/nonCoreJar1.jar /system/framework/nonCoreJar2.jar /system/framework/...nonCoreJarN.jar
unodex
for k in /system/framework/bootClassPathJarN.jar /system/framework/bootClassPathJarN-1.jar /system/framework/...bootClassPathJarN-y.jar
unodex
it requires a couple of reboots along the way to deal with any created dalvik-cache so that it doesn't interfere with the next needed classes.dex
the only turn-off was that it requires a running system to do it (it's not that big of a problem, but porting and then flashing starts getting old after a while).
Has that changed?
Does OP mean you can take the apks, toss them into a folder, and then do it from the computer without the phone?
Click to expand...
Click to collapse
Yea I would figure as much ... simply b/c one must follow the BOOTCLASSPATH order when odex'ing ...
So Jubeh .. you're saying you've personally de-odex'd an fully odex'd framework b4?
Just looking for confirmation from someone who has personally ... since I'm too lazy to go through that hectik crappy process
~enom~
enomther said:
Yea I would figure as much ... simply b/c one must follow the BOOTCLASSPATH order when odex'ing ...
So Jubeh .. you're saying you've personally de-odex'd an fully odex'd framework b4?
Just looking for confirmation from someone who has personally ... since I'm too lazy to go through that hectik crappy process
~enom~
Click to expand...
Click to collapse
I did it with the tattoo build, but upon boot I would get all sorts of fc's, but I think that was due more to a bad, hasty port than the deodexing. It was also a long time ago when the tool first came out, dont know if there's been newer revisions, so I'll try it again on that funky tattoo rom.
K guys one problem i found after doing multiple apk's is that i need to give the listening dex command a bit delay so its ready for baksmali. I was doing it right after which it misses for some conversions. I'll upload with delay between the two commands. Hmm framework i gotta give a shot :/ Sounds interesting ...
Solid script! Should make deodexing A LOT easier
Ok so i uploaded with delay between, seems to work fine, tested a LOT of times
thanks for this! can't wait for frameworks to be de-odexed.
jubeh: Thanks for the info. I had no idea and have informed JF previously here: http://jf.andblogs.net/2009/11/08/smalibaksmali-v1-0/ (see comments)

[HOW-TO] Re-Odex a ROM

I made a tutorial for other devices here http://forum.xda-developers.com/showthread.php?t=1500475
Why this tutorial?
I wanted a good odexed rom, but there isn't any here. So I tried to make my own odexed rom, but it wasn't so good. So I read something about re-odexing and tried it out. I modified it a little bit and I don't know all about re-odexing, so if someone know something better, pls post it here in the thread for everyone. Im working also on this thread, so I'll try to make few things like a flashable update.zip who executes the script. English is also not my mother language, but I hope you'll understand me
What is a odexed and a deodexed rom?
When you look at a stock rom in the folder /system/app, you will see files with the ending .odex and the apks doesn't contains classes.dex files. When you look at a deodexed rom, you'll see that there are no .odex files and the apks contains classes.dex files. Basically every apk contains a classes.dex files. Then the dalvik virtual machine generates a dalvik cache based of the classes.dex file. When you load a app, it will be loaded from the the dalvik cache, not from the apk. Samsung built the odexed rom using a tool called dexopt-wrapper. This tool generates .odex files based from the classes.dex, that means it does the same job like the dalvik vm. The .odex files were pushed in the /system. The files are the replacement for the dalvik cache. Like I wrote above, apps are loading from the dalvik cache, not from apk or classes.dex file, so classes.dex are not needed anymore, so they are deleted in odexed roms. Deodexing using xUltimate means regenerating a classes.dex based from the .odex file, merging it into the apk and deleting .odex.
What are the advantages and disadvantages from a deodexed rom?
Advantages:
-All needed things are in one apk, so modding/theming is (better) possible
-Needs less space on /system
Disavantages:
-Needs more space on /data, you have on some roms only 110/170 mb free(because a deodexed rom needs a dalvik cache for system apps and frameworks
-Is not so stable than a odexed rom(because some moves dalvik cache to a low end sdext)
-Slower on first boot(because a odexed rom has already execute ready .odex files, a deodexed rom needs to generate dalvik cache)
Why should I re-odex?
I wanted this, because I use ~100 apps and I have a slow sd card, so moving /data/app and /data/dalvik cache to sdext made my system unstables, which was needed to run ~100 apps on a deodexed rom. But when I tried it on a odexed rom, I had only to move /data/app to sdext. So I used long time Stock rooted JPU. But the system was not so fast than on any other custom rom and I hated the stock theme. So If you want more space on /data and you don't want to try out new themes, you should probably try re-odexing.
What do I need to re-odex?
-A full NANDroid Backup
-More than 30 mb free space on /system
-ADB drivers for Option 1
-Titanium Backup Pro for Option 2
How can I re-odex a Rom?
There are 2 Options to do it, but only the first does a full re-odex.
Before doing anything make sure that you have a full NANDroid Backup because you'll propably get into a bootloop.
Option 1 using dexopt-wrapper:
I used first the script from puppet13th, but I got into a bootloop. So I corrected the $BOOTCLASSPATH and corrected permissions, but I got also into a bootloop. I compared the re-odexed Kyrillos Rom v9.3 framework with the framework from JPU. The difference was that Kyrillos Rom v9.3 Framework files android.policy.jar and services.jar doesnt contained the Meta-Inf.
Step 1: Check jars
Pull all your framework .jars using this adb command to your computer
Code:
adb pull /system/framework
and open them in WinRar or sth and check that they contains the Meta-Inf folder. If some file doesnt contain a Meta-Inf folder, I attached all jars from Stock JPU, so you can add the Meta-Inf folder from them. When you are done with adding Meta-Inf Folder to one file, you can push it to the system using this adb command(services.jar is only for example, use your filename):
Code:
adb push services.jar /system/framework
Some users told me that you can re-odex the rom without being in CWM, so you can may skip Step 2, but you could get into a bootloop without Step 2, but you can try it out, there is no risk with a NANDroid backup
Step 2(optional): Reboot your phone into cwm recovery and get adb access there
I never got adb access in windows, but i got always access with linux. If you also don't get access on Linux, you should try to reboot your phone and to select then recovery in the extended power menu, this gaves me always adb access.
Step 3: run reodex script
I attached a script, which push a script and needed binaries over adb to the phone. Then it executes the pushed script, which creates odex files and removes classes.dex from apks or jars and rezipaligns apks and deletes the dalvik cache.
For windows users: double click on odex.cmd
For linux users: open a terminal and navigate to the folder which contains the unzipped attachment and run
Code:
chmod +x reodex.sh
./reodex.sh
After its finished, simply reboot and enjoy your fully re-odexed rom.
Step 4 (optional) convert /data:
I dont know if there is a better option, but after a re-odex with Option 1, my phone didnt showed the right free space on /data. So I converted /data to a other filesystem and back and then it showed the right free space.
Option 2 using Titanium Backup Pro:
You need to have Titanium Backup pro for re-odexing.
Step 1:
Select Menu -> More -> integrate sys dalvik into rom and wait until its finished. Then you should have more space on /data. I had when I tried it before 105 and after 135 mb free space on /data and 0kb free space after it on /system, so its not all.
You can also undo it. Its good when you want to try out a new theme, so you can undo and redo it using TB Pro.
Simply select Menu -> More -> Undo sys dalvik integration
and you're done.
Option 1 vs. Option 2
-Option 1 does a full re-odex, you have full free space on /data(Option 2 does only re-odex the apps, not the framework)
-Option 1 deletes classes.dex from apks and jars(against Option 2), so you have more space free on /system
-You can undo Option 2 fast, so theming/modding is also possible by undo, theme and redo it(against Option 1)
For other Phones:
If someone has a other phone, theres a chance for getting re-odex working, but I think that you should not hope that it works. You can try to put in the right $BOOTCLASSPATH. You can find the valid $BOOTCLASSPATH in /init.rc. Then replace the following characters with the $BOOTCLASSPATH in the script in the folder odex(beginning from Line 8):
Code:
BOOTCLASSPATH=replace_this_with_your_bootclasspath
cd /system/framework
for filename replace_this_with_your_bootclasspath
In the line
Code:
for filename replace_this_with_your_bootclasspath
you must replace the ":" character between framework files with a space.
For theme developers:
I dont know if it works that you use the re-odexed theme on a stock odexed theme. If it is so, you dont have to re-odex and deodex your phone, you can simply push the dexopt-wrapper binary to a folder, chmod 755 it and use it to make odex files from the needed apks and jars(all apks inside /system/framework has no odex files, so dont odex them) like this:
Code:
dexopt-wrapper /system/app/Phone.apk /mnt/sdcard/Phone.odex /system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
You can change argument 1-2, but not argument 3(its the BOOTCLASSPATH)Then you could copy all needed main apks or jars to sdcard and remove classes.dex. Then only do Step 1 from Option 1 and you should have a theme for odexed rom.
Download Links
XDA gaves me only 500 Errors when uploading was done, so I uploaded it to min.us
Framework jars from JPU
Re-Odex Script for Windows
Re-Odex Script for Linux
Credits
puppet13th for making orginal script
If I helped you, dont be shy, just press the Thanks Button under this post.
www.kingsrom.com/f8-how-to-theme-guideslinkstutorials
Oh year I didnt see any tutorial before, but his is only for Froyo sense or Gingerbread aosp, so it wont work on galaxy 3 and I also wrote my tutorial so that noobs can understand it(I hope so).
I could also post a system.img of a re-odexed Kyrillos Rom v9.3 and other Roms, but I dont know if Im allowed to do that.
TearsDontFalls said:
Oh year I didnt see any tutorial before, but his is only for Froyo sense or Gingerbread aosp, so it wont work on galaxy 3 and I also wrote my tutorial so that noobs can understand it(I hope so).
I could also post a system.img of a re-odexed Kyrillos Rom v9.3 and other Roms, but I dont know if Im allowed to do that.
Click to expand...
Click to collapse
So the re-odexed kyrillos rom v9.3 is working faster than the original kyrillos rom v9.3??
Its not generally faster, but much faster for me because I have ~100 apps and when I run these apps on kyrillos v9.3 deodexed, i must move app and dalvik-cache to sdext which made my phone laggy. With a odexed kyrillos v9.3, i have much more space free on /data, so i only must move app to sdext which is much.
I wrote also the advantages and disadvantages from a deodexed and odexed rom in my tutorial.
TearsDontFalls said:
Its not generally faster, but much faster for me because I have ~100 apps and when I run these apps on kyrillos v9.3 deodexed, i must move app and dalvik-cache to sdext which made my phone laggy. With a odexed kyrillos v9.3, i have much more space free on /data, so i only must move app to sdext which is much.
I wrote also the advantages and disadvantages from a deodexed and odexed rom in my tutorial.
Click to expand...
Click to collapse
So, in a re-odexed rom the HD2SD is not working ?
You use again froyo data2SD ?
dante_100 said:
So, in a re-odexed rom the HD2SD is not working ?
You use again froyo data2SD ?
Click to expand...
Click to collapse
As far as I understand, it works but only for data/app.
correct me if I'm wrong
Sorry, my english is not the yellow from the egg(you must not understand this).
Im using on my re-odexed rom also Hybrid Data 2 SD, I can move also move /data/dalvik-cache and any other folder to sdext, its only not needed, because I had after the re-odexing much more free space on /data, so I did moved dalvik cache back to the NAND from the sdext, before re-odexing I moved dalvik cache to sdext, becaue it was needed for running ~100 apps.
short form:Only Theming is impossible with a re-odexed rom
Hope you'll understand this now.
Edit: Can someone help me for creating a update.zip for re-odexing. It must only copy the dir odex to /data/local/tmp/odex , chmod 755 them all and execute the shell script /data/local/tmp/odex/odex
Sooo
if i get ADB access using windows i can skip step 2 in option1 right?
chandradithya said:
Sooo
if i get ADB access using windows i can skip step 2 in option1 right?
Click to expand...
Click to collapse
No. You need to reboot in cwm and try to get adb access from there. Windows adb in recovery never worked for me, you need linux to get adb access from cwm mode
Sent from my i9003 powered by Poseidon's Rom + UC kernel
Right, I tried to make a update.zip which execute the script, but i had no success, it would be great if somebody can help me.
bscraze said:
No. You need to reboot in cwm and try to get adb access from there. Windows adb in recovery never worked for me, you need linux to get adb access from cwm mode
Sent from my i9003 powered by Poseidon's Rom + UC kernel
Click to expand...
Click to collapse
ADB actually works for me, just ran cmd.exe using admin privileges and i ran the odex script it worked, odexed ALL my system files, cleared my /data/dalvik-cache/
But like TearsDontFalls said it doesn't show the free memory correctly,
Im running g3mod and im yet to try the option4 that asks you to switch file systems
And the /g3mod.log says,
st17: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
While the other partitions are all clean,
How did you got adb access in windows? Sure you was in cwm recovery while re-odexing?
Finally, someone post a guide on this. And it works! Though titanium backup never worked for me. And is it necessary to run the script on cmw? Cause I didn't done it on cmw.
Sent from my GT-I5800 using XDA App
I didn't expect that it works on a running system, but it can be so, so I'll update the guide after Christmas.
TearsDontFalls said:
How did you got adb access in windows? Sure you was in cwm recovery while re-odexing?
Click to expand...
Click to collapse
It worked perfectly for me,
I tried going to the G3 kernels recovery, ADB just wouldnt connect,
so i turned it on, Ran the script when it was in standby mode , then it gave an error at first,
Which i rectified by making the /system read or write using root explorer,
I think i ran the script using admin privileges.
Dont remember..
And g3mod.log showed me this
Code:
Checking mmcblk0p2
/dev/block/mmcblk0p2: clean, 11/125488 files, 15840/500173 blocks
Checking stl6
/dev/block/stl6: clean, 1302/13600 files, 46914/54400 blocks
Checking stl7
/dev/block/stl7 contains a file system with errors, check forced.
/dev/block/stl7: Inodes that were part of a corrupted orphan linked list found.
/dev/block/stl7: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Checking stl8
/dev/block/stl8: clean, 12/2176 files, 143/8704 blocks
Data2SD Disabled
Multi-OS Data Disabled
System detected: FROYO
System booted with Samsung Froyo kernel mode
Compcache disabled
No problems right now, But cant stop wondering why it says it is inconsistent.
I don't know why it is so, but it also doesn't show the right free space, so convert it to a other file system and then convert it back.
UNBELIEVABLE!
Finally, the first method worked for me.
Working great on HTC Amaze 4G
Thanks
heyjoe66 said:
UNBELIEVABLE!
Finally, the first method worked for me.
Working great on HTC Amaze 4G
Thanks
Click to expand...
Click to collapse
Thanks for your report. So it seems to be working on other devices, so I'll create a thread in android development.
Thanks works on sense 3.5, but I had to change Bootclasspath from the boot.img and add missing files below in odex script.
great guide
edit: now searching on how to re odex a single file.

[Explained] Difference between Odex and Deodex?

Odex versus Deodex​
As an Android newbie, what bothered me most was coming across terminology beyond my comprehension. Not coming from a Linux background it became hard to keep up with the oh-so-commonly-used words spread all across the development community. Likewise, since I didn’t understand the terms, consequently I was unable to determine is something was of any use to me or not. From what I have seen, this problem extends to many novice and even average users.
One commonly occurring word when playing with custom ROMs and firmware, and even themes is deodexed and odexed. Most users fail to understand what these terms actually imply, and while developers would boast again and again about their themes and ROMs being deodexed, the average user is left clueless as to what is going on.
What is an .odex file?
In Android file system, applications come in packages with the extension .apk. These application packages, or APKs 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 in a certain way, such that they are reassembled into classes.dex files. By doing that, all pieces of an application package are put together back in one place, thus eliminating the worry of a modified APK conflicting with some separate odexed parts.
In summary, Deodexed ROMs (or APKs) have all their application packages put back together in one place, allowing for easy modification such as theming. Since no pieces of code are coming from any external location, custom ROMs or APKs are always deodexed to ensure integrity.
How this works
For the more geeky amongst us, Android OS uses a Java-based virtual machine for running applications, called the Dalvik Virtual Machine. A deodexed, or .dex file contains the cache used by this virtual machine (referred to as Dalvik-cache) for a program, and it is stored inside the APK. An .odex file, on the other hand, is an optimized version of this same .dex file that is stored next to the APK as opposed to inside it. Android applies this technique by default to all the system applications.
Now, when an Android-based system is booting, the davlik cache for the Davlik VM is built using these .odex files, allowing the OS to learn in advance what applications will be loaded, and thus speeds up the booting process.
By deodexing these APKs, a developer actually puts the .odex files back inside their respective APK packages. Since all code is now contained within the APK itself, it becomes possible to modify any application package without conflicting with the operating system’s execution environment.
Advantages & Disadvantages
The advantage of deodexing is in modification possibilities. This is most widely used in custom ROMs and themes. A developer building a custom ROM would almost always choose to deodex the ROM package first, since that would not only allow him to modify various APKs, but also leave room for post-install theming.
On the other hand, since the .odex files were supposed to quickly build the dalvik cache, removing them would mean longer initial boot times. However, this is true only for the first ever boot after deodexing, since the cache would still get built over time as applications are used. Longer boot times may only be seen again if the dalvik cache is wiped for some reason.
For a casual user, the main implication is in theming possibilities. Themes for android come in APKs too, and if you want to modify any of those, you should always choose a dedoexed custom ROM.
Full credits to the source: addictivetips.com
Update: Here's a link to the Universal Odex Script made by MatrixDJ96
Thanks mate, You really saved my lot of time.:good:
Native7i said:
Thanks mate, You really saved my lot of time.:good:
Click to expand...
Click to collapse
You're welcome!
I really wanted to know about that, since people mention it a lot lately, thanks
Nice write up very proffesional this should be stickied for new users
Sent from my SCH-I500 using Tapatalk 2
Thanks!
Thanks! helped me alot! very informative.
The best explanation
If you want, you can share my universal odex script for all phone in your thread
Sent from my GT-I9100 using xda app-developers app
Thank you. As a newbie, I learned a lot from your explanations.
MatrixDJ96 said:
The best explanation
If you want, you can share my universal odex script for all phone in your thread
Sent from my GT-I9100 using xda app-developers app
Click to expand...
Click to collapse
Hey MatrixDJ96
I've added the link to your script.
Wow, this was a real lifesaver :victory: I finally can differentiate
:good:
nice write up
Thanks
Thanks, Really help a lot...
that was a really clear explanation - thanks!

ART Runtime in Android 4.4(kitkat)

What is ART?
ART stands for Android runtime which is a new runtime like Dalvik which is introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer option.n 4.4 both runtimes are now available, Dalvik runtime (libdvm.so) and the ART (libart.so).The user can choose it from developer options.
Click to expand...
Click to collapse
Difference between Dalvik and ART
Dalvik
Dalvik runtime uses JIT(Just-In-Time) compilation to interpret Bytecode
Now lets understand the technical info and terms in the above sentence.
Click to expand...
Click to collapse
Compiler
A compiler is a program or set of programs that transforms source code written in a programming language (the source language) into another computer language
Click to expand...
Click to collapse
Bytecode
Bytecode also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter
Click to expand...
Click to collapse
Interpreter
Interpreter is a program which translates the source code into computer/machine language
Click to expand...
Click to collapse
JIT compliation
JIT compliation interprets the bytecode into machine language at it's runtime (at the time when the apps are executed).
Click to expand...
Click to collapse
Now summing up all these Dalvik runtime does everything when the apps are executed. Now this is where we must discuss odexed and deodexed ROM. usually all stock ROMs released by OEMs are only odexed only due to this reason. odex means a part of the app is already compiled and it is written into dalvik VM(VM=Virtual Machine). and it runs at boot so while execution of apps JIT has to compile only the remaining part of the code when the apps is executed, this is why odexed ROM is faster than deodexed ROM.
But the disadvantage of odexed ROM is it cannot be edited/themed easily as a part of code is seperated in a separate file, and deodexing means the odex part of the file is put back into the apk/jar itself which makes editing/theming easy since the full code is packed inside a single file but it decreases speed because JIT has to compile full code when the app is executed
ART
ART uses AOT compilation to interpret bytecode.
I hope you can refer to dalvik paragraph to know about these technical terms.
Click to expand...
Click to collapse
what is AOT compilation
AOT is a method of compilation which compiles the code into machine language when the app is installed itself, means no compilation is done at the time of execution of app. This makes the apps launch speed amazingly fast.
Click to expand...
Click to collapse
Advantages of ART over Dalvik
The apps launch speed is amazingly fast in case of ART since nothing is compiled at execution.
Boot speed is faster than dalvik since nothing is execued from dalvik partition as in case of odexed ROM in dalvik
Increases battery backup by reducing CPU work due to absence of compilation work on apps execution.
And finally it is a great reward to developers because most of developers are worried that odexed ROMs are faster than deodexed ROMs but they will deodex their ROMs since they heavily theme it. In case of ART whether the ROM is odexed or deodexed it doesn't matter, it compiles the full code into machine language on installation of apps. so even deodexed ROMs are as fast as odexed in ART
Click to expand...
Click to collapse
Some disadvantages of ART
Since ART precompiles apps on installation, it takes 10-20% more space upon installation than dalvik. But this can be simply solved by using apps like apps2sd/link2sd/gl2sd when your apps storage partition is full
One more is since it is only experimental feature now some apps are incompatible in ART which will be made compatible soon on their updates.
Click to expand...
Click to collapse
Here is the list of apps which are compatible and incompatible in ART.
http://www.androidruntime.com/list
Finally ART is one of the best feature that google brought up in android 4.4 (kitkat)
so, what if I get a rom like that which is on the nexus 6, and it has apks and odex files, how can you deodex these apks, there oviously odexed, because apks like maps are split compared to the deodexed apk, so are they not able to be odexed, or how can this be done
PradeepMurugan said:
What is ART?
Difference between Dalvik and ART
Now summing up all these Dalvik runtime does everything when the apps are executed. Now this is where we must discuss odexed and deodexed ROM. usually all stock ROMs released by OEMs are only odexed only due to this reason. odex means a part of the app is already compiled and it is written into dalvik VM(VM=Virtual Machine). and it runs at boot so while execution of apps JIT has to compile only the remaining part of the code when the apps is executed, this is why odexed ROM is faster than deodexed ROM.
But the disadvantage of odexed ROM is it cannot be edited/themed easily as a part of code is seperated in a separate file, and deodexing means the odex part of the file is put back into the apk/jar itself which makes editing/theming easy since the full code is packed inside a single file but it decreases speed because JIT has to compile full code when the app is executed
Here is the list of apps which are compatible and incompatible in ART.
http://www.androidruntime.com/list
Finally ART is one of the best feature that google brought up in android 4.4 (kitkat)
Click to expand...
Click to collapse
gigawatt said:
so, what if I get a rom like that which is on the nexus 6, and it has apks and odex files, how can you deodex these apks, there oviously odexed, because apks like maps are split compared to the deodexed apk, so are they not able to be odexed, or how can this be done
Click to expand...
Click to collapse
I would first ask you have you seen any such rom first? Mostly 5.0(Lollipop) ROM doesn't have odex files. I own a Nexus 7 2013 LTE version and I am using 5.0. Still now I have used many Lollipop ROMs but i haven't came across any odex files because In lollipop ART is the only Runtime unlike in 4.4. So There is no need of .odex files in lollipop.
P.S : Some claim that they have .odex files in lollipop rom But i haven't seen it. If i get to know it is true or not then we may get a clear conclusion
well, on the nexus 6 there is a folder for each app and inside is an apk file for the app, in some cases a lib folder with lib files inside and then an arm folder with a .odex file, so, either this is an odexed rom, or the files are there as place holders, but there rather large for place holders
PradeepMurugan said:
I would first ask you have you seen any such rom first? Mostly 5.0(Lollipop) ROM doesn't have odex files. I own a Nexus 7 2013 LTE version and I am using 5.0. Still now I have used many Lollipop ROMs but i haven't came across any odex files because In lollipop ART is the only Runtime unlike in 4.4. So There is no need of .odex files in lollipop.
P.S : Some claim that they have .odex files in lollipop rom But i haven't seen it. If i get to know it is true or not then we may get a clear conclusion
Click to expand...
Click to collapse
gigawatt said:
well, on the nexus 6 there is a folder for each app and inside is an apk file for the app, in some cases a lib folder with lib files inside and then an arm folder with a .odex file, so, either this is an odexed rom, or the files are there as place holders, but there rather large for place holders
Click to expand...
Click to collapse
well even I have lib folder and arm folder but there is no odex file inside them

Root / Custom Roms: Odexed and Deodexed, what's the difference?

For those interested in Custom ROMs and the modding scene, you've probably already heard of the terms ''odexed'', a characteristic of Android ROMs and ‘’deodexed'', an element known from custom ROMs. But what exactly hides behind these two terms and which advantages or even disadvantages does each one present? Well, let me explain...
Odexed
With an odexed ROM, you'll find files which end with .odex within the system app folders. This stands for ''Optimized Dalvik Executable File''. Browser.apk and browser.odex will appear in the /system/app folder as well.
But what's an .odex file?
And most importantly, for what is an .odex file used? It serves the purpose of organizing the system structure which contains application information (start up, usage, etc) and allows Android to access this information without having to go search for them and decompress them from .apk files. Odex files are directly loaded into the dalvik cache, which you've probably heard of when talking about wiping before or after flashing a ROM. This allows your system to run a lot quicker.
Advantages of an Odexed ROM
-Applications start a lot faster since the important information has already been loaded by the system beforehand.
-The .apk files are not as big, therefore they take up less room.
Disadvantages
App modding/themes/hacking becomes a lot more difficult because the code is now found in two different locations.
If you delete some of the app data, the .odex file must also be deleted in order to avoid errors.
The usual classes.dexfiles files in an APK: here are the ones from the navigator / © AndroidPIT
Deodexed
When it comes to a deodexed ROM, all of the application information is found in an .apk file. The code found in the .odex files are added to the apk under the name classes.dex.
Advantages
Deodexed is a lot easier for modding/themes/hacking, because the data is found within the APK.
System apps are easier to delete, since only the APK must also be deleted.
Disadvantages
The program library can't be loaded beforehand, therefore slowing down the app start.
Bootloading also slows way down because the APK content first needs to be taken from the system for the reason that a direct access is no longer present.
It's important to note that these two disadvantages quickly go unnoticed since the dalvik cache stores information that has been extracted from the APK and saves it, to then be retrieved later on. Longer loading times would then be a direct consequence of emptying the Dalvik cache in the event of a Custom Recovery.
Bottom Line
Android versions which come directly from manufacturers are in most cases odexed. Custom ROMs on the other hand are deodexed nine times out of ten, which allows them to take up less room and offer more customization possibilities. So there you have it: odexed versions are optimized for speed, while deodoxed is better for hacking, themes and modding. Simple, right?
Right sir?
Enviado desde mi SM-N910S mediante Tapatalk

Categories

Resources