[Samsung Galaxy W I8150] pepoluan:
Famous answer: It depends. :D

Explanation:

Many ROMs, especially based on Stock ROM, has no support for theming since the base (Stock) has no support for theming. For these ROMs, theming is done by patching the relevant .apk files. And this is not possible if the .apk files have been odex-ed.

However, CM9 (and, perhaps, CM10) has built-in support for theming; theming is not done by patching. Instead, a theming engine inside CM9 will read the necessary resources from a theme file and use those resources to draw the on-screen components. Thus, odex-ing .apk's on such ROMs have no effect to the themeability of the ROM.

.odex stands for "optimized dex"

Simplified technical explanation:

On first use, Android will extract a ".dex" file from inside the .apk file. This .dex file is a 'partially-compiled' object file, which will then be recompiled by the phone to be runnable on the phone's Dalvik VM. Due to time-pressure (i.e., you *don't* want to wait one minute just to open an app), recompilation is usually performed using a "JIT" (Just-In-Time) method; i.e., only necessary portions of the .dex is recompiled, other portions are not if the user does not ask for it. This results in lags as user accesses parts of the app that have not been JIT-recompiled. The result of JIT-recompilation is saved in the Dalvik Cache to save time the next time the app is accessed. Due to space-pressure, sometimes objects in the Dalvik Cache gets deleted; this means, the app needs to be recompiled again when it's executed.

System apps (i.e., those whose .apk's are located in the /system/app directory) is handled slightly differently: Rather than being JIT-recompiled, it's fully compiled on first use (e.g., after flashing a new ROM, or after wiping the Dalvik Cache). This means that, inside the Dalvik Cache, the recompiled code is 'complete'. *However*, the recompiled code is *not* immune to purging.

odex-ing means that 'complete' recompiled code is extracted from the Dalvik Cache and placed alongside the system app's .apk; this cuts down the recompilation time if the Dalvik Cache gets purged.

The existence of an odex also signals Android to not spend time reparsing the .dex files if system components get killed (e.g., when system is memory-pressured by a big game); system apps will come back to life much quicker because all Android has to do is 'dump' the .odex files' contents into the Dalvik Cache.

Finally, since recompilation (of system apps) now no longer happens, CPU spikes due to recompilation should happen much less frequently, thus helping to save battery.

Now, the drawbacks:

Usually, if you odex-ed an app, you'll want to remove the .dex files in the .apk. After all, there's no point in keeping them, right? They all have been recompiled into odex files.

However, doing so removes 'well-known' patching points of the .dex. As a result, mods -- including theme-mods -- no longer work because they can't find the patching points. (And no, odex patching points are *not* reliable as you're delving into binaryland there...).

The "Odex Me" app (available somewhere in the MoDaCo forums) does exactly that: It removes dex files from apks while attaching odex files to the apks.

CM9 does not like losing its dex-es.

The "Integrate sys Dalvik" method of TiBU is less radical: It attaches the odex files to the apks, but does not remove the dex files from within the apks. As a result, it's reversible. Drawback of this method: Since the dex files still exist, the Android system will first extract the dex files and prepare it for recompilation. Only after doing that will it notice the odex files and dump the odex-es into Dalvik Cache; that is why you'll see "Android Upgrading" pop-up on every boot.

As usual, be very careful; you're 'messing up' with important parts of your phone, there ;)

Create nandroid backup

Open TiBu, tap Menu, choose "Integrate sys Dalvik into ROM"

Reboot

Test everything's going well

If the worst happens, you can always restore the nandroid backup :cool: