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

[GoogleCodeExporter]

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.j
ar
deodexerant /system/app/gtalkservice.odex 1234 &
exit
tcp forward tcp:1234 tcp:1234
baksmali gtalkservice.odex -x :1234

Original comment by [email protected] on 1 Jan 2010 at 5:31

[GoogleCodeExporter]

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

Original comment by [email protected] on 1 Jan 2010 at 5:32

[GoogleCodeExporter]

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.

Original comment by [email protected] on 1 Jan 2010 at 5:32

[GoogleCodeExporter]

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

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

Original comment by [email protected] on 1 Jan 2010 at 5:34

[GoogleCodeExporter]

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)

Original comment by [email protected] on 1 Jan 2010 at 6:06

[GoogleCodeExporter]

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

Original comment by [email protected] on 1 Jan 2010 at 6:07

[GoogleCodeExporter]

 "/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.

Original comment by [email protected] on 1 Jan 2010 at 6:10

[GoogleCodeExporter]

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 :) 

Original comment by [email protected] on 1 Jan 2010 at 6:10

[GoogleCodeExporter]

Original comment by [email protected] on 1 Jan 2010 at 6:13

• Changed state: Done

[GoogleCodeExporter]

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

Original comment by [email protected] on 1 Jan 2010 at 6:28

[GoogleCodeExporter]

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

Original comment by [email protected] on 1 Jan 2010 at 6:38

[GoogleCodeExporter]

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.

Original comment by [email protected] on 1 Jan 2010 at 6:58