Seeing as how Android is fast becoming one of the fastest growing smartphone and tablet platforms out there, it’s surprising to note how little clear information is available for the uninitiated towards the platform that would actually explain what certain terms – those that experienced users are so familiar with that it seems second nature to them – mean.
XDA-Developers is one of the largest and most useful sources for learning Android, but let’s face it; the forum has all the information within it without a stellar search engine, and the user community, while being helpful, would mostly advise you to ‘use the search feature’ instead of answering all the beginner question that you may have. Thus, users are often found looking for those answers in places other than the forum. Well, I cannot promise answers to everything, but if you’re trying to comprehend the difference between a odexed and deodexed ROM, you’ve come to the right place!
Explaining Odexed vs. Deodexed Android ROMs
You’re bound to have come across the term ‘deodexed’ if you’ve ever installed a custom firmware on your device, since almost all ROM developers choose to deodex their offerings. What this means for the average user, however, is a different story. To understand the concept, you’ll first need to grasp what odex files are, and why are the present in the OS in the first place.
Android (being based on Linux) uses application packages, or APKs, as they’re normally called, to tell the operating system what app to load and execute. If you’re at all familiar with Android, you’ll know that the OS works on the basis of partitions, out of which those apps that are contained in the /system partition are system apps (and cannot be changed or modified without having root level access, since they’re a part of the OS itself), while those contained within the /data partition are user apps and can be freely modified. The /system partition is the first one to load when the operating system boots up, hence giving priority to the apps contained within. It is with these apps that odex and deodex deal with.
What Are The Two Possibilities
Coming back to Android applications, there are two possible routes to follow, based on the fact that each app is comprised of an APK and a cache part that tells the Android Dalvik Virtual Machine (VM) what components does the app come with.
- The cache for each APK is contained separately in a .odex file, which loads into the virtual machine at the time of boot, thus speeding up boot times. (Odexed)
- The cache for each APK is contained within the APK itself as a classes.dex file, making the boot times slower as Dalvik VM is built up. (Deodexed)
Now, ideally, most OEMs choose to opt for the first route, for two major reasons. First, it makes modifying the system apps more difficult (thus making the OS more stable and secure), and two, faster load times for the OS itself, since the cache is built as part of the virtual machine itself. Confused? Allow me to explain.
Clearing Up the Confusion
In normal cases, where an Android firmware is odexed, the .odex files for each /system APK (which are stored outside of the APKs themselves) are written into the Dalvik Virtual Machine when the OS boots up. Since these .odex files contain preliminary load information about each system app, the OS knows what to expect when it’s booting up, and consequently, loads all these apps faster. Ultimately, for the user, it means that boot times are significantly sped up, and you can put your device to use much sooner.
As opposed to the above, in a deodexed (custom) ROM, there is no cache information within the Dalvik Virtual Machine at the time of boot, so when the system status up, it only gets to know which apps to load once the /system partition APKs are actively accessed. This, in effect, will result in a much longer boot time, since each APK will be processed one by one, and you will be able to use your device long after you’ve powered it up.
Deodex is Slower, Then Why Bother?
In real life, that’s not the case. With deodexed ROMs, only the first ever boot after clearing Dalvik cache is slower, and all subsequent ones will be the same as any odexed ROM. This is owing to the fact that during the first boot, all cache information is written to the virtual machine anyway, and hence, it will behave as any other firmware (until you clear the Dalvik cache once again).
Why ROM developers do it is because of the modification possibilities that it entails, especially theming. Since in a deodexed scenario, all the application code is contained within one single APK, the developer can simply modify the APKs values to apply any custom look and feel to the app itself, without breaking any functionality. This also opens up possibilities for changing different parameters of the app without affecting how others will operate. Since a dodexed package has no external dependencies, it gives more freedom to modify what they wish. On the other hand, with an odexed ROM, theming is absolutely impossible, since the .odex part of the application will always be in conflict.
The Bottom Line
It all boils down to this: while an odexed firmware is faster and more secure, a deodexed one gives more modification freedom, and is the only way possible to change the look and feel of system apps. In actual terms, deodexed ROMs are only slower in the first ever boot, after which they are the same speed as the former ones. Also, deodex doesn’t entail any serious security risks to your device, either, and you can rest assured that the millions of users opting for these aren’t suffering.
You can follow us on Twitter, add us to your circle on Google+ or like our Facebook page to keep yourself updated on all the latest from Microsoft, Google, Apple and the web.
