4 ms·

OT, but this jumped out to me: > In the same way that a compiled Android binary bears little resemblance to the original Java source code From what I recall,

OT, but this jumped out to me: > In the same way that a compiled Android binary bears little resemblance to the original Java source code From what I recall, Java binaries actually look a lot like their source code. They're not human-readable of course, but you can decompile them very easily and get fairly good code back out. This made Minecraft an easy game to mod: just decompile a class, change a line or two, recompile, insert back into the JAR and you're done. Is Android different?

hn_throwaway_99 9y ago
Not really. The bytecode format (.dex) is different, but it's straightforward to convert dex files back to jar files, and then decompile the jar and get readable Java source.
- pjmlp 9y ago
  But it won't be "the original Java source code", specially with ProGuard and more advanced Java constructs, or even if another JVM language is being used.
pjmlp 9y ago
That is only true on a naive compilation, that doesn't make much use of language features introduced since Java 7. Many companies make use of bytecode obfuscators to make it harder to translate back. In Adroid not only is obfuscation part of the build process (ProGuard), there is the additional step of converting from Java bytecodes into DalvikVM bytecodes. So if you only have DalvikVM bytecodes, you might translate to something back that looks like Java, but it won't be the original code.
izacus 9y ago
Android code goes through ProGuard on release usually, which is an optimizer (and obfuscator if enabled). It usually makes a lot of optimizations on bytecode level which makes decompiled code noticably harder to read.
- kuschku 9y ago
  If you disable the obfuscation, ProGuard code still looks basically the same. I never enable the obfuscation, as my apps are GPL anyway, and I want users to be able to just decompile any version.
  - izacus 9y ago
    Not really - ProGuard does several optimizations (finalization, removal of redundant bytecode instructions, pulling up methods into superclasses, removing needless sublcasses, some fixes to handling exceptions and several other things depending on optimization settings) which change the bytecode output to the point where you don't have a two-way mapping from Java to compiled code anymore.
    - kuschku 9y ago
      I know, and it gets a lot worse when using Kotlin, but this ensures that users can always take the compiled binary, and check that it doesn’t use any analytics, tracking, or any proprietary code that might violate their privacy. This is very important for me.

hn_throwaway_99 9y ago

Not really. The bytecode format (.dex) is different, but it's straightforward to convert dex files back to jar files, and then decompile the jar and get readable Java source.

pjmlp 9y ago
But it won't be "the original Java source code", specially with ProGuard and more advanced Java constructs, or even if another JVM language is being used.

pjmlp 9y ago

That is only true on a naive compilation, that doesn't make much use of language features introduced since Java 7. Many companies make use of bytecode obfuscators to make it harder to translate back. In Adroid not only is obfuscation part of the build process (ProGuard), there is the additional step of converting from Java bytecodes into DalvikVM bytecodes. So if you only have DalvikVM bytecodes, you might translate to something back that looks like Java, but it won't be the original code.

izacus 9y ago

Android code goes through ProGuard on release usually, which is an optimizer (and obfuscator if enabled). It usually makes a lot of optimizations on bytecode level which makes decompiled code noticably harder to read.

kuschku 9y ago
If you disable the obfuscation, ProGuard code still looks basically the same. I never enable the obfuscation, as my apps are GPL anyway, and I want users to be able to just decompile any version.
- izacus 9y ago
  Not really - ProGuard does several optimizations (finalization, removal of redundant bytecode instructions, pulling up methods into superclasses, removing needless sublcasses, some fixes to handling exceptions and several other things depending on optimization settings) which change the bytecode output to the point where you don't have a two-way mapping from Java to compiled code anymore.
  - kuschku 9y ago
    I know, and it gets a lot worse when using Kotlin, but this ensures that users can always take the compiled binary, and check that it doesn’t use any analytics, tracking, or any proprietary code that might violate their privacy. This is very important for me.