I wasn’t aware of the DALVIK_VM_BUILD property. That will certainly be helpful to help distinguish what inline methods should be used.

At some point, I also want to read the dependencies from that area and automatically try to load them, instead of having to specify them manually via a command line parameter.

I figured things would change at some point – and I that I would have to deal with them when they did. I decided to go this route rather than the native binary mainly for ease of use. It was a pain to have to run the deodexerant binary on the phone.

Hopefully the vtable indexes and field offsets won’t change as well. But if they do, I’m sure I’ll figure out how to handle that also.

Thanks for the heads up and the info! Much appreciated

Something to think about:

There’s a value in the dependency area of a .odex file that has the value of the DALVIK_VM_BUILD constant (look for it in the sources to see where it’s placed). It’s updated whenever something that affects the validity of .odex files changes, like the inline method table, field layout, vtable ordering, etc. You may want to pull that out and make it available.

I mention this because the contents of gDvmInlineOpsTable are going to change in the next release, and there’s really no other way to identify what was used. (The DALVIK_VM_BUILD is not part of the version in the header because changing the inline methods doesn’t change the structure or interpretation of the DEX file itself, e.g. dexdump continues to work as before.)

The fact that eclair simply extended donut is a trend that’s about to break. (Sorry.) FWIW, donut version=14, eclair=17, future is not yet written.

Hey Where are you still missing the Old G1 days with RC29 Update.

This post was mentioned on Twitter by cyanogen: http://jf.andblogs.net/2010/02/22/smali-baksmali-1-2-released/…

You are a scholar and a gentleman. Thank you ever so much for this hack and your hard work.

And God bless the internets and all their tubes!

Jim