[Hero, G2 Touch Android Development] jubeh:
Yeah, I mentioned on the earlier post that doing "format DATA:" and "format CACHE:" would be the equivalent of running "Wipe data/factory reset" from the recovery menu since you mentioned about making a build that installs fresh. Paul's (MoDaCo) roms are no-wipe, so they preserve that program data and instead format all other directories inside /data that might be problematic during an upgrade; his roms use apps2sd, so he assumes that the user's downloaded apps are in mmcblk0p2 (the memory card's ext partition), so by formatting /data/app, he's only erasing the apps he included in his update package, if the user doesn't use a2sd, well, this erases their downloaded apps (one of the reasons I dislike the current a2sd implementation, it's not suited for all situations). Then he deletes data/init.sh, which is basically a script he includes in /data that runs during a rom's boot and starts things like a2sd, compcache, linux-swap, and other custom rom's "advanced" features. DATA:local is also app storage (I believe) and functions much like in windows' /users/x/application data/local, it can be problematic if not done between builds. Last, he erases /data/dalvik-cache, this is where the temporary application code resides (the extracted classes.dex from inside an apk) for rapid execution (for apks that haven't been pre-odexed). If you wish to make your rom no-wipe, add those lines instead of "format DATA:", but I'd remove "delete DATA:app" since it's a bit problematic for people who don't use a2sd.

dumpstate is a debugging tool that android uses, but I don't know exactly where or how (I think it's an HTC-specific log for their HTCLog.apk). It contains two tools, dumpcrash and bugreport, much like toolbox is a binary that contains all the tools you see symlinked to it in update-script (bin, df, cp, mv, ls, insmod, etc.). It's not a problem at all if you remove it, but it's not a problem either to leave it there. Whenever something is symlinked, though (if it's something you added, for example, busybox tools), you have to make sure that the binary or a link to it or a previous symlink to it doesn't exist, otherwise your update-script will fail (like symlinking toolbox's insmod and then busybox's insmod, or busybox's ping if a ping binary already exists in the target symlink directory (for example /system/bin)).

I guess that could work if you modify network type (there's a property somewhere in there about HSXPA, I think), but like you said, there's no documentation so it calls for some experimenting.

Those properties are also overrides, so, for example, if your rom doesn't do adb root (because ro.secure is set to 1 in init.rc), you can add ro.secure=0 in build.prop to enable adb root again.

Most properties are self explanatory, and pretty much, if you can't tell what it is, you probably shouldn't change it (for example, build.fingerprint allows you to change what kind of apps Market presents to you).

I'd say, don't mess around too much with the first batch (default build properties), with the exception of build.fingerprint.

The classes.dex files is the dalvik bytecode for the application. It contains everything inside /appnamespace/src and /appnamespace/R if you're working from the source. It's basically all the java code already compiled for the dalvik virtual machine.

Dalvik doesn't do jit, so the classes.dex have to be extracted (if they're not already) and run through the virtual machine in a process called dexopt that produces code that can be much more rapidly excecuted by the dvm (dalvik virtual machine). The extracted code is then placed in /data/dalvik-cache (mentioned earlier) as partname@app@apkname.apk@classed.dex. All this pre-cached code eats away at your space in your /data partition (where you store your system data, like your email, messages, browser cache, and downloaded applications) and can be quite a big chunk of space gone (framework classes specially, since all jars inside /system/framework are nothing but java code, about 20MB for all framework code).

The solution to prevent usage of /data storage on an initial build is to have the code pre-extracted. This is done at compile-time running the created system through an emulator and then creating the odex files, which is almost exactly the same as the *@classes.dex found inside /data/dalvik-cache except that it's much better aligned to the device's memory configuration and offers (marginally) better excecution, plus when the package manager first encounters the apk, it's first step is to check if an .odex of it is available, if it is, then it skips checking and dexopting a classes.dex inside it and proceeds to the next package.

Odex files increase the space in your /system partition (it was already read-only, so it's not like you're missing out on something) so those 20 MB of framework that would have been tossed into your userdata partition are now out of the way into the useless (in an available-storage sense) /system partition so you have more free space for your apps.

There's a tool that can create odex files for apks that don't have them, it's called dexopt-wrapper and it has to be run from a running phone. However, this tool won't strip the (now unnecessary) classes.dex from inside an apk, so it has to be done manually. Removing the classes.dex once you've created an odex is a good idea merely on the basis of space savings. However, once a classes.dex has been odexed, it's very hard (used to be impossible) to turn it back to a classes.dex and place it inside an apk.

Usually, us rom cooks preffer the classes.dex inside the apk because odexes create conflicts when you try to mix and match apps between builds. Since the odex files are tied to the framework where they were created, adding an apk with it's odex to another framework (even one that's only ever-so-slightly different) will be very problematic (the odex code is no longer protected or verified, so the rom won't even boot because it will fail verification for all available packages).

The tool for reverting odex files is called deodexerant by jesus freke. It requires working knowledge of how the system goes through the dexopting process so you can run it in the proper order.

Another thing to know is that even if your /system is pre-odexed, your downloaded apps will still be run through the package manager and have their classes.dex dexopted and placed in /data/dalvik-cache.

Oh, and never, ever put odexes anywhere but /system/framework or /system/app (or /data/app_s if you use a2sd). The package manager currently can't handle odexes in /data/app or /data/app_private (the other two locations where it looks for packages other than /system/app).

In the end, whether to use/have odexes comes down to personal choice (and available space). There's two hero builds, those based in 2.73.405.61 and 2.73.405.66, that have not been pre-odexed, so they're perfect for experimenting, mix/matching, etc...