so no news about obfuscating with Proguard? On Aug 4, 10:47 pm, DanH <danhi...@ieee.org> wrote: > "And my experience (non-Dalvik, to be sure) is that 'Class loading > time > goes up, execution efficiency is reduced' is incorrect, that the > opposite results -- in fact, that's one of the reasons to consider > obfuscation despite the pitfalls -- so I think bad advice is being > handed out with the good here. Another positive is that application > size goes down -- I've never seen nor heard of an exception to that." > > Keep in mind that there are obfuscators and there are obfuscators. > Some only replace non-external symbols with shortened ones and maybe > remove any unreferenced methods (which actually deobfuscates to a > degree). They don't really touch the bytecodes. These are reasonable > with regard to performance (reduces class size slightly), but not > particularly effective in terms of stopping a halfway determined > hacker. > > Other obfuscators attempt to prevent individual methods from being > decompiled by changing the order of the code, inserting arbitrary > branches and exception handlers and the like. These are a bit more > effective at stopping hackers, though any hacker worth his salt could > figure out how to write a deobfuscator for one of them. I've seen > cases where this sort of obfuscated code takes minutes to verify vs > seconds, due to these changes. Other cases where the JVM just choked > on the class and threw up. (There is a test case out there that I > wrote, known as BigUglyMethod.java -- maybe 100 lines of code. The > folks at Sun likely hate it because it broke their verifier and caused > them a heap of hurt. I got the idea on how to write it by observing > obfuscated code.) > > On Aug 2, 11:53 am, Bob Kerns <r...@acm.org> wrote: > > > I disagree. It's off topic. > > > Except for the point about it being harder to decompile Dalvik byte > > codes, but that's just a matter of some tool development work. > > > And my experience (non-Dalvik, to be sure) is that "Class loading time > > goes up, execution efficiency is reduced" is incorrect, that the > > opposite results -- in fact, that's one of the reasons to consider > > obfuscation despite the pitfalls -- so I think bad advice is being > > handed out with the good here. Another positive is that application > > size goes down -- I've never seen nor heard of an exception to that. > > > Anyway -- it looks to me like your problems stem from not starting > > from a working ant build and then adding obfuscation. > > > If you follow the documented approach for creating a new ant build > > project, and then move your code into it, you should have a working > > build virtually out-of-the-box. You can then turn that into a NetBeans > > project or Eclipse project without much trouble, and get the benefits > > of both worlds. Probably even all three is doable! > > > Then, once you have that working ant build, extend it with an > > obfuscation step. I haven't done that yet -- but having seen how the > > base ant build is generated, I absolutely would not try it without > > first having a solid ant build in place. Then you would not be > > experiencing errors like tasks not defined or missing targets. > > > The negatives are real, and one is that it will take you some time to > > set it up and get right, and a lot of testing to make sure it's > > right. But I think it will go faster if you start with a blank ant- > > build project, get that solid, and then add obfuscation. > > > On Aug 1, 3:46 pm, Indicator Veritatis <mej1...@yahoo.com> wrote: > > > > Pointing out the pitfalls of obfuscation is NOT "moving the thread off > > > topic". For in order for you to understand the answer to your > > > immediate question, "has anyone had success" at it, you have to > > > understand what 'success' could MEAN in the context. And DanH has been > > > quite generous with exactly the background to understanding how > > > limited that success will be. > > > > On Jul 30, 9:46 am, sblantipodi <perini.dav...@dpsoftware.org> wrote: > > > > > You are so kind answering me and I really appreciate it > > > > but there are many answers, all are off topic. > > > > I haven't asked if it is good to obfuscate or if I need to switch to > > > > NDK, > > > > I asked if someone succeded obfuscating standard android class using > > > > ant. > > > > > Please don't move this thread off topic. > > > > Thanks to all. > > > > > On Jul 30, 5:37 pm, DanH <danhi...@ieee.org> wrote:> Keep in mind that > > > > what goes onto the phone isn't Java bytecodes but > > > > > rather the Dalvik translation. Much harder to back-translate than > > > > > bytecodes. > > > > > > (I've seen obfuscated bytecodes and it's not pretty. Class loading > > > > > time goes up, execution efficiency is reduced, the odds of hitting a > > > > > bug, either in the obfuscator or in the JVM, is greatly increased.) > > > > > > On Jul 30, 9:11 am, sblantipodi <perini.dav...@dpsoftware.org> wrote: > > > > > > > Ok, thanks for the suggestions, any other idea? :) > > > > > > > On Jul 30, 2:59 pm, DanH <danhi...@ieee.org> wrote: > > > > > > > > Just say no to obfuscation. > > > > > > > > On Jul 30, 3:36 am, sblantipodi <perini.dav...@dpsoftware.org> > > > > > > > wrote: > > > > > > > > > Since I'm going mad trying obfuscating my projects on Netbeans > > > > > > > > and > > > > > > > > it's not reasonable > > > > > > > > at the moment for me to switch to Eclipse I need a command line > > > > > > > > script > > > > > > > > that let me > > > > > > > > build and obfuscate my APK... > > > > > > > > > Is there some example script, or some tutorial that could help > > > > > > > > me in > > > > > > > > this "intent"? > > > > > > > > Thanks. > >
-- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
