[G1 Android Development] jubeh:
This is just a hint about how to properly run dexopt-wrapper so that you can do it for framework too. I learned this by checking logcat.

I first started creating odexes back with JF's builds when we thought that odexes were the reason ion builds were so fast. Although that was eventually proven wrong, there are two latent benefits to having odexed apps; decreased usage of dalvik-cache (thus, more space in /data) and decreased first-boot time after a wipe.

The disadvantage of odexed apps is that, unless the classes.dex is kept inside the .jar or .apk, the app and framework are bound to each other (though an odexed framework can still be used under a full set of non-odexed apks, but not the other way around). This removes mix-and match, and it was the reason why I was waiting for a more current hero-dump that didn't have all it's apps and frameworks odexed.

One problem I've seen with roms that try using odexes is that the classes.dex is left inside the apk. I don't know yet whether this is intentional or not, but removing the .dex saves space (as it's no longer needed), but it won't ever be as small as just keeping it inside the apk (because inside, it's compressed), but having it both inside the apk and outside in dalvik-cache is redundant, i feel. Donut does a much better job at this, but I feel there's still room for improvement (why not use the largely unused /cache partition?).

Another problem I've seen is that roms that do have properly odexed app folders don't also odex the framework, and that's a biggie. Most of framework is nothing but dalvik executables, and their caches write about 15 MB to /data. To preserve space in data, I think these are a priority. I feel that whether or not /app is odexed is of less concern than not odexing framework, since it's immovable. The reason people don't odex frameworks, though, is because things just seem to break right afterwards. The problem is that regular odexing scripts just take an alphabetical aproach to dexopt-wrapper, but, looking at logcat, one realizes that there's actually an order on which this should be done.

First, we have to do (in order) what I call the "Core framework":

core.jar

then ext.jar

then framework.jar

then android.policy.jar

then services.jar

Secondly, we get into what I call the "Secondary Framework", it's basically all the frameworks that haven't been odexed yet, and order doesn't seem to matter anymore after that, so you can do it alphabetically, however, looking at logcat, dalvik vm does it in this order:

com.android.im.plugin.jar

com.google.android.gtalkservice.jar

android.test.runner.jar

com.google.android.maps.jar

android.awt.jar

svc.jar

pm.jar

monkey.jar

input.jar

ime.jar

framework-tests.jar

Be careful that your script doesn't try to create odexes for apks inside framework, as they have no classes.dex, but the wrapper will still create an .odex for it and cause problems.

last, you dexopt-wrapper /app folder, this is important, if you do app first, you'll get Android Runtime start problems because the dalvik code is not unprotected, so it wont pass verification (an odexed framework is, in a sense, a different version than a non-odexed).

After you get all your odexes. You can just go adb pull /system or adb pull /system/framework/*.odex and pull /system/app/*.odex and use those odexes to re-pack your build, removing classes.dex from inside apks and jars, and packing the odexes along with them.

Also, be sure that if you want to keep an app's ability to be upgraded, don't odex it (actually, don't even have it in /system, toss it to /data/app)