/* * Your warranty is now void. * I am not responsible for bricked devices, dead SD cards, * thermonuclear war, or you getting fired because the alarm app failed. Please * before flashing it! YOU are choosing to make these modifications, and if * you point the finger at me for messing up your device, I will laugh at you. */
What is ODEX and DEODEX?
Android uses application packages, or APKs as they’re normally called, to tell the operating system what app to load and execute. The framework, that contains others packages, with JARs extension, is the first part of the OS that is in /system partition and it is the first one that is loaded when the OS boots up.
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 VMwhat components does the app come with.
The cache for each APK is contained separately in a .odex file, which loads into the Dalvik VM at the time of boot, thus speeding up boot times. (ODEX)
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. (DEODEX)
Now, ideally, most OEMs choose to opt for the first route, for two major reasons. First, it makes modifying the system apps more difficult (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. In normal cases, where an Android firmware is odexed the .odex files for each /system APK and JAR are written into the Dalvik VM 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 VM at the time of boot, so when the system status up, it only gets to know which files to load once the /system partition APKs and JARs are actively accessed. This, in effect, will result in a much longer boot time, since each APK and JAR will be processed one by one, and you will be able to use your device long after you’ve powered it up. 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). 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.
Summary of ODEXED ROM
It's fast to open system app, has more stability and more battery life, uses less RAM than DEODEXED ROM but it's a little bit complex to customize APKs and JARs and is a little bit slower to boot up.
Summary of DEODEXED ROM
It's slower than an ODEXED ROM to open system app, has less stability and less battery life, uses badly RAM but it's a "easy" customization of APKs and JARs and is a little bit faster to boot up.
Odexer Tool (OT) is a script that allow you to odex your ROM in a safety way without using a PC. I worked a lot of time to make it and so if you like it, please give a thanks.
1 -> Odex Framework in /system/framework/*.jar
2 -> Odex Apps in /system/app/*.apk
3 -> Odex Apps in system/priv-app/*.apk
4 -> Remove classes.dex from JARs/APKs (if emabled)
frame -> odex all framework
sysapp -> odex all system apps
all -> odex all ROM
set -> enable/disable 'Remove classes.dex'
I think that it is dangerous to ODEX the ROM because you are touching Android completely. With OT I made a safety way to ODEX but there us always a possibility to soft brick your device. I suggest you to use it when you are at home with a PC (and not when you are out) if something goes wrong.
No, i dangerous because if something goes wrong (for example during framework odex), there is more possibility to soft brick the device but if you have Honey Comb, Ice Cream Sandwich or Jelly Bean you must enable it if you don't want message "Android is upgrading" on every boot.. On KitKat is really dangerous because some older rom (first KitKat built) this option will soft brick at 100% your device.
Honey Comb (3.x.x)
Ice Cream Sandwich (4.0.x)
Jell Bean (4.1.x, 4.2.x, 4.3.x)
I need only 4 things!
First, DEODEXED (or partial) ROM.
Second, custom recovery to flash OT.
Third, some free space in /system (check below).
Fourth, a working brain!
Framework -> 14% or more of free space in system.
System apps -> 23% or more of free space in system.
All ROM -> 31% or more of free space in system.
First of all be sure to have a chance to restore everything!
1 -> Download Odexer Tool (link in second post)
2 -> Reboot into recovery
3 -> Install Odexer Tool
4 -> Reboot into system
5 -> Open Terminal Emulator
6 -> Type 'su' to obtain root access
7.a -> Type 'odex' to show possible command/s
8.a -> Type one of the possible command/s that is available
8.a -> Waiting and enjoy!
7.b -> Type 'odex one of the possible command/s' (for example 'odex all')
8.b -> Waiting and enjoy!