bootclasspath - /system/app/gtalkservice.odex de-odex error about smali

[JesusFreke]

Comment #1 originally posted by JesusFreke on 2010-01-01T05:31:29.000Z:

You need to set the BOOTCLASSPATH environment variable on the phone. Not on your
computer :)

adb shell
BOOTCLASSPATH=$BOOTCLASSPATH:/system/framework/com.google.android.gtalkservice.jar
deodexerant /system/app/gtalkservice.odex 1234 &
exit
tcp forward tcp:1234 tcp:1234
baksmali gtalkservice.odex -x :1234

[JesusFreke]

Comment #2 originally posted by JesusFreke on 2010-01-01T05:32:30.000Z:

dedexer can de-odex "app\gtalkservice\gtalkservice.odex" without problems.

[JesusFreke]

Comment #3 originally posted by JesusFreke on 2010-01-01T05:32:30.000Z:

Also, for the record, you don't have to deodex
/system/framework/com.google.android.gtalkservice.odex first. You can just deodex
/system/app/gtalkservice.odex, if that's all that you're interested in.

[JesusFreke]

Comment #4 originally posted by JesusFreke on 2010-01-01T05:34:13.000Z:

baksmali/deodexerant can deodex it fine. You just have to do it correctly.

Also: interesting. I wasn't aware dedexer could do deodexing now.

[JesusFreke]

Comment #5 originally posted by JesusFreke on 2010-01-01T06:06:22.000Z:

Yes. dedexer can do odex files now. I just tried other odex files
with "baksmali/deodexerant", and most of them are fine (Calculator.odex etc. worked
well). However, I had a similar problem with "GmailProvider.odex", see below:

C:\android-sdk_r04\smali>java -Xss1m -Xmx512M -jar baksmali.jar -x :1234 GmailProv
ider.odex

UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.RuntimeException: java.lang.RuntimeException: class
Lcom/google/android/gtalkservice/GTalkHttpClient; could not be found for common
superclass lookup
at org.jf.dexlib.Util.Deodexerant.sendCommand(Deodexerant.java:193)
at org.jf.dexlib.Util.Deodexerant.lookupCommonSuperclass
(Deodexerant.java:167)
at org.jf.dexlib.Util.DeodexUtil$insn.findCommonSuperclass
(DeodexUtil.java:1241)
at org.jf.dexlib.Util.DeodexUtil$insn.propagateRegisters
(DeodexUtil.java:1412)
at org.jf.dexlib.Util.DeodexUtil$insn.propagateRegisters
(DeodexUtil.java:1466)

[JesusFreke]

Comment #6 originally posted by JesusFreke on 2010-01-01T06:07:47.000Z:

You just need to add the extra dependency jar to the BOOTCLASSPATH environment
variable on the phone, before running deodexerant.

[JesusFreke]

Comment #7 originally posted by JesusFreke on 2010-01-01T06:10:36.000Z:

"/system/app/MarketUpdater.odex" is good with "baksmali/deodexerant". Just
that "/system/app/gtalkservice.odex" and "/system/app/GmailProvider.odex" have dep
problems, not be de-odexed at this point. This is from Google ADP2/Sapphire rom.

[JesusFreke]

Comment #8 originally posted by JesusFreke on 2010-01-01T06:10:39.000Z:

I do want to add functionality to deodexerant so that it reads the dependencies from
the odex file and automatically sets the bootclasspath appropriately. But for now,
you have to set it before calling it :)

I haven't taken a look at dedexer in a while. It looks like he's been doing some work
on it :)

[JesusFreke]

Comment #9 originally posted by JesusFreke on 2010-01-01T06:13:14.000Z:

<empty>

[JesusFreke]

Comment #10 originally posted by JesusFreke on 2010-01-01T06:28:11.000Z:

Thanks JF!
Yes. After export
BOOTCLASSPATH=$BOOTCLASSPATH:/system/framework/com.google.android.gtalkservice.jar,
it works perfect now!

[JesusFreke]

Comment #11 originally posted by JesusFreke on 2010-01-01T06:38:42.000Z:

How come dedexer can do it offline on host, and has no dependence issue?

[JesusFreke]

Comment #12 originally posted by JesusFreke on 2010-01-01T06:58:03.000Z:

It's because he took a different path to deodex stuff than I did. When a dex file is
odexed, various instructions are replaced with an "optimized" version of the
instruction. For things like invoke-virtual, instead of directly specifying the name
of the method that should be invoked, the odex instruction instead contains the index
into the vtable that dalvik keeps for each class.

What dedexer does (or appears to do, I haven't looked at the source much yet), is to
load the dependency odex files, and recreate the virtual tables, so that he can
resolve the virtual table indexes in the odexed instructions. Like most things, his
approach is a trade-off. On the positive side, it is a lot easier to use, since you
don't have to be running a helper binary on a device. On the negative side, it's
possible that dalvik's internal representation of the vtable will change, and his
deodexer will no longer work with the new format, without changes.

On the other hand, I chose to use a method that is more robust, but is more difficult
to use. My method should be able to handle changes in dalvik's internal
representation easier, but it's more difficult to use.