zdzhjx / android-apktool

Automatically exported from code.google.com/p/android-apktool
Other
0 stars 0 forks source link

different size of classes.dex when decompiling and recompiling same file #775

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Decompile APK
2. Recompile same APK without any changes

What is the expected output? What do you see instead?
I expected to see the same classes.dex file but the recompiled apk had a file 
with different size.

What version of the product are you using? On what operating system?
2.0.0-RC4 on Windows

Please provide any additional information below.
I've decompiled the new APK and searched for differences in the .smali files. 
I've noticed that line like those (in the original APK):
.field public static result:Landroid/content/Intent; = null
became (in the recompiled APK):
.field public static result:Landroid/content/Intent;

and:
.field public static final TEST_android_focusable:I = 0x0
became:
.field public static final TEST_android_focusable:I

Original issue reported on code.google.com by mr.je...@gmail.com on 3 Mar 2015 at 10:23

GoogleCodeExporter commented 9 years ago
Can you try not using apktool at all, and use the smali project for disassemble 
and rebuild, and then disassemble again?

https://code.google.com/p/smali/

That'll let me know if it is a problem in the flavor of smali we use or 
upstream or even a problem at all.

Original comment by connor.tumbleson on 4 Mar 2015 at 1:55

GoogleCodeExporter commented 9 years ago
I've tried it and it seems to be a problem of smali/baksmali.
I've used baksmali and then smali right away, and the new classes.dex file was 
different than the original, I'll post this issue on the smali project page.

Original comment by mr.je...@gmail.com on 4 Mar 2015 at 10:07

GoogleCodeExporter commented 9 years ago
Okay, let me know of the outcome.

Original comment by connor.tumbleson on 4 Mar 2015 at 12:24

GoogleCodeExporter commented 9 years ago
I see in issue #235 at smali that this isn't a problem, that the initializers 
handle the setting of null/0.

Thanks for following up with smali with that.

Original comment by connor.tumbleson on 11 Mar 2015 at 12:13