hosijyun / smali

Automatically exported from code.google.com/p/smali
0 stars 0 forks source link

Smali error with FRF83 #36

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What seems to be the problem? Getting issues rebuilding classes.dex file with 
smali v1.2.3.. Classes.dex is deodoxed from FRF83 Froyo 2.2. services.jar.

What is the exact smali/baksmali command that you ran?
java -Xmx512M -jar smali.jar classout/ -o new-classes.dex

What version are you using? v.1.2.3.

Please provide any additional information below: error messages, symptoms,
etc.

Original issue reported on code.google.com by brovic777@gmail.com on 25 Jun 2010 at 9:22

Attachments:

GoogleCodeExporter commented 9 years ago
Did you modify the file at all?

Also, can you pastebin the snippet of smali code that it is complaining about?

Original comment by JesusFr...@gmail.com on 25 Jun 2010 at 1:23

GoogleCodeExporter commented 9 years ago
Yes, file was modified here on statisbaricon.smalli to modify date text color 
to cyan:

    .line 60
    const/high16 v6, -0xff0001

I ran it without editing it and smali worked fine, but once edited to change 
color it errors. 

Attached if both the classout folder zipped. Unzip so you can run smali 
yourself and see it if gives you the error also. And attached is the 
statisbaricon.smali file where the code was changed. 

Original comment by brovic777@gmail.com on 25 Jun 2010 at 9:57

Attachments:

GoogleCodeExporter commented 9 years ago
This is the expected behavior. That instruction takes the specified short value 
(16 bits) and then shifts it left by 16 bits and loads it into the specified 
register. But the literal value you are trying to use can't fit into 16 bits, 
and so it (correctly) errors out.

The literal value for that instruction is limited to 16 bits, because anything 
more than 16 bits would get shifted off when the left shift is performed. This 
instruction can obviously only be used when the literal value you want only 
contains zeros in the low-order 16 bits. But for the cyan color, the low order 
16 bits are actually all 1s. So you can't use the const/high16 instruction.

Also: Why do you insist on using a negative value? Color codes are much easier 
to specify as a positive value. See my comments about this here: 
http://forum.sdx-developers.com/themes/(how-to)change-lockscreen-clockdatenetwor
k-font-color/msg54854/#msg54854

If you want a cyan color (i.e. #00FFFF RGB), you should use

const v6, 0xff00ffff

Original comment by JesusFr...@gmail.com on 25 Jun 2010 at 11:39

GoogleCodeExporter commented 9 years ago
Sweet!!!! Your code fix worked!!!!!! 

Posted credits for you for helping crack the color code! 

http://forum.xda-developers.com/showthread.php?t=700703

Original comment by brovic777@gmail.com on 26 Jun 2010 at 5:04