Odex and Deodex
ODEX and DEODEX
I'm sure you have seen this one before. All in all this is one of the commonly used expresions across the custom rom community. The funny thing is though, a lot of people don't know what it means. So don't feel stupid, the majority of us is in the same ˝not knowing˝ boat. If you're ignorant of how this stuff works you'll stop reading right about now.
You don't need this to flash your beloved phone. Well, technically yes. But I'm not seeing things that way. Curiosity and sharing is important. Without it there would be no articles, guides, how to's and so forth on the internet. And that is the main reason I'm writing this. To provide you with the information and save you time because you don't have to look all over the place for it. It's on you to make (or not) use of it.
This article will give you just a basic explanation so after reading it through you'll have a basic understanding of what these terms mean. Also, trying to impress the girl next door with this new found knowledge is a no-go (as a matter of fact it'll make you look geeky) so don`t even try. On the other hand it will help you to determine if something in custom rom is of any use to you or not. Enough with it already, lets get on with how it works.
WHAT IS AN ODEX FILE?
Odex file is the extracted and optimized DEX file (classes.dex) from APK or JAR files. An ODEX file has dependencies on every file in the BOOTCLASSPATH that is loaded when it is generated. The odex file is only valid when used with these exact BOOTCLASSPATH files. Dalvik enforces this by storing a checksum of each file that the odex file is dependent on, and ensuring that the checksum for each file matches when the odex file is loaded.
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. They are ˝optimized” Dalvik executable file. 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. The odexed file structure works well as an optimization tool, except for the most cases of theming. Odexed apps and frameworks present a unique problem to those wanting to theme because the aspect they want to theme is broken up into two files.
IN SHORT: Pre-optimized parts of an application or library
In these ROMs you will have ODEX files for most APK and JAR files in /system/framework and /system/app and also the classes.dex in APK and JAR files will be missing.
- speed up loading as odex is uncompressed and already optimized
- saves space as no need to put optimized dex in Dalvik-cache (already have the ODEX file in /system/framework or /system/app)
- hard to hack/decompile as data is separated
- cannot make modifications to apks or jars
- cannot be themed
- cannot change BOOTCLASSPATH if system libraries are affected
LETS DO DEODEX NOW
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.
IN SHORT: the process of reassembling odex files in dex (classes.dex) and place them back in the respective APK and JAR files.
In these ROMs you will have classes.dex file in all APK and JAR files.
- can make modifications to apks
- can be themed easily
- can change/add/remove libraries and thus recompile all the current apks with the new implementation
- slower loading but just the one time when a modification is done or Dalvik-cache cleaned(wiped).
- space needed to put optimized dex in Dalvik-cache
- easier to decompile an app
AND HOW DEODEXING WORKS?
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.
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.
Robbie Hood likes this.