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

[JesusFreke]

Original issue 13 created by JesusFreke on 2010-01-01T04:37:22.000Z:

What steps will reproduce the problem?

1. De-odex /system/framework/com.google.android.gtalkservice.odex first
2. De-odex /system/app/gtalkservice.odex, and got dependence errors even
   if "-Xbootclasspath/a:.\framework\gtalkservice" is used.

What is the expected output? What do you see instead?

Please see errors in the additional section below.

What version of the product are you using? On what operating system?
Windows Vista 32, JDK 1.6.17, ADP2/Sapphire phone.

Please provide any additional information below.

C:\android-sdk_r04\recovery\smali>java -
Xbootclasspath/a:.\framework\gtalkservice -Xss1m -X
mx512M -jar baksmali.jar -x :1234 app\gtalkservice\gtalkservice.odex

UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.RuntimeException: java.lang.RuntimeException: class
Lcom/google/android/gtalkservice/Group
ChatInvitation; could not be found for common superclass lookup. This can
be caused if a library the
odex depends on is not in the BOOTCLASSPATH environment variable
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)
at org.jf.dexlib.Util.DeodexUtil$insn.propagateRegisters
(DeodexUtil.java:1466)
at org.jf.dexlib.Util.DeodexUtil$insn.propagateRegisters

.....................

(DeodexUtil.java:1466)
at org.jf.dexlib.Util.DeodexUtil$insn.propagateRegisters
(DeodexUtil.java:1466)
at org.jf.dexlib.Util.DeodexUtil.makeInsnList(DeodexUtil.java:188)
at org.jf.dexlib.Util.DeodexUtil.deodexerizeCode
(DeodexUtil.java:194)
at
org.jf.baksmali.Adaptors.MethodDefinition$MethodItemList.generateMethodItem
List(MethodDef
inition.java:207)
at org.jf.baksmali.Adaptors.MethodDefinition.getMethodItems
(MethodDefinition.java:158)
at org.jf.baksmali.Adaptors.MethodDefinition.makeTemplate
(MethodDefinition.java:62)
at org.jf.baksmali.Adaptors.ClassDefinition.getDirectMethods
(ClassDefinition.java:255)
at org.jf.baksmali.Adaptors.ClassDefinition.makeTemplate
(ClassDefinition.java:75)
at org.jf.baksmali.baksmali.disassembleDexFile(baksmali.java:120)
at org.jf.baksmali.main.main(main.java:198)
Caused by: java.lang.RuntimeException: class
Lcom/google/android/gtalkservice/GroupChatInvitation; c
ould not be found for common superclass lookup. This can be caused if a
library the odex depends on
is not in the BOOTCLASSPATH environment variable
at org.jf.dexlib.Util.Deodexerant.sendCommand(Deodexerant.java:189)
... 104 more

[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.