Comments on: smali/baksmali v1.0

By: anthony

anthony — Tue, 12 Jan 2010 23:05:52 +0000

Hi JF, thanks in advance for any help that you give me. I de-odexed my services.odex file on my CLIQ and the program put everything in the out directory. (I am trying to change the color on my notification bar.) I edited my files and am ready to rebuild. Everything that I have read about rebuilding the services.odex file goes something like this…

java -jar baksmali.jar -o < .dex file

Now here is where I get confused. Is a .odex file the same as a .dex file? Or do I have to perform another step for an .odex file?

Thank You

By: Twitted by Wysie_Soh

Twitted by Wysie_Soh — Mon, 14 Dec 2009 13:50:48 +0000

[...] This post was Twitted by Wysie_Soh [...]

By: jf

jf — Mon, 14 Dec 2009 01:37:00 +0000

Yeah, you can definitely deodex everything in any order you want, as long as you don’t replace any jars/apks on the phone until after you’ve deodexed everything. I’m 100% certain about that. Don’t believe anyone who says otherwise

By: Jubeh

Jubeh — Sun, 13 Dec 2009 20:45:49 +0000

I see how that makes sense. I was with the logic where, if you create odexes for a build, you first have to follow the boot classpath and then do all the rest because there are dependencies generated (in some way, I don’t understand fully how) based not only on the dalvik machine and memory configuration but also the running framework, so if you dexopt-wrapper the apps, then the secondary framework, then the core framework, there will be a lot of broken dependencies since the information written to the original apps odexe’s were dependent on the original configuration of the classes for the framework (non-odexed) and when you odex the framework after that, it breaks all that. Again, I’m not entirely sure why that is, but that’s what seems to be happening.

Anyway, I thought this was the same situation, but thinking about it, it makes sense that those dependencies are stripped when you de-odex, and as long as you don’t change anything in the current build from which you’re running deodexerant, the applet should be able to determine those dependencies, memory configurations, etc and strip those to leave you with the kind of “universal” dex code we all know and love.

I hope I’m on the right track.

By: jf

jf — Sun, 13 Dec 2009 02:06:23 +0000

The only reason you would need to deodex stuff in any particular order is if you deodex one file, and then resmali it and put it back on the phone, and then deodex the next file, etc. But if you just deodex everything before replacing any files on the phone, you don’t have to deodex them in any particular order. Much easier

As for the services.odex issue, I’m aware of it, and working on a fix. In the meantime, just replace the goto/16 or goto instructions that it complains about with a goto/32 instruction instead.

By: Jubeh

Jubeh — Sat, 12 Dec 2009 23:22:18 +0000

I’m also at the same point as you, though. services deodexes just fine, but then trying to smali it back will fail.
I know now my approach is correct and I should be able to de-odex the core framework by doing it in the reverse order of which it dexopts for the first time, but services.jar happens to be the very last jar to be de-odexed and while the others will de-odex fine (except etc.jar, it will throw a bunch of errors and won’t baksmali completely), even if I try to boot with core, framework, and android.policy de-odexed, services and ext will fail verification (ofcourse) and the system will just hang at a boot loop.
I’m mentioning it because I’m very sure the problem is with smali/baksmali.
My test rom is the adp1 ota image for 1.6. What? you say, that build doesn’t have any odexes, does it?.
Well, no, it doesn’t, but I ran dexopt-wrapper all over it and then baksmali-ed it all back to classes.dex for fun (yeah, i was that bored, research actually). So to replicate, just download the image from developer.htc.com (oh, they’re down) and dexopt-wrapper it and then try to deodexerant it back.
I have to ask, JF, which build are YOU using. I’d like to test compiling the framework on that.

By: Wysie

Wysie — Fri, 11 Dec 2009 03:34:41 +0000

Hi JF, jubeh@xda has posted some stuff regarding framework de-odexing here: http://forum.xda-developers.com/showpost.php?p=5121020&postcount=14

Hope it helps .

By: Wysie

Wysie — Mon, 07 Dec 2009 03:26:04 +0000

by the way, is your email JesusFreke[at]JesusFreke.com? I can email you the odex files later . thank you.

By: Wysie

Wysie — Mon, 07 Dec 2009 02:53:01 +0000

Hey jf, thanks for the reply! Nope, I did not modify the file at all, was simply trying to de-odex services.odex and framework.odex. Had trouble de-odexing framework.odex, and services.odex works but I can’t compile it back using smali.

I’m using it on Amon_RA’s ROM here: http://forum.xda-developers.com/showthread.php?t=538645

Thanks JesusFreke!

By: jf

jf — Sun, 06 Dec 2009 21:39:32 +0000

Did you modify that smali file before re-assembling it? If so, it’s possible you inserted some code between the goto/jump and its target, and made the target out of range.

BUT, if you didn’t modify it at all, that’s certainly very strange. If that’s the case, what rom did you take the services.odex from? A dl link to the rom would be appreciated – or you could email the odex file to me.