From what I've seen and read, if someone really wants to reverse-engineer your software or decompile it, ProGuard is not going to stop them. But is it at least a modest deterrent? I'm not sure if it's worth the hassle of translating my stack traces later on.
I would recommend ProGuard. Even without obfuscation (which can significantly shorten the names used in the constant pool) it can remove "dead code" (unused methods) of used libraries, etc. (It can also be used to conveniently merge everything together).
It takes a little bit of fiddling to "get correct", esp. if there is dynamically loaded classes -- but very recommended. The actual benefit from space-saving, however, "depends" on what can be eliminated and generally goes up with more external libraries.
Now, for obfuscation -- it does as much as any obfuscator: Makes "decompiling" code into things with meaningful names impossible.
Obfuscation won't save your super-secret-algorithm or hide your private keys, though: if the JVM (or Dalvik after a transformation) must understand it, then so can a decompiler and anyone who really wants to get access can. Your code could even be lifted in bytecode-form and used simply via. reflection (just imagine a terrible API with zero documentation): anyone who really wants to get access can. But perhaps obfuscation will make this task unfeasible for the cost/payout: "It depends".
Don't want to translate stack-traces? Simple: don't use it for debugging (not as useful for getting traces from users) or don't enable obfuscation (other benefits still apply) ;-)
Happy coding.
Pro guard is at least enabling you to have the app become as small as possible regarding the filesize!
That's a real plus.
It's automatically used when developing and compiling with eclipse, provided if you have proguard.config=proguard.cfg to the project's default.properties file.
That's also a real plus.
来源：https://stackoverflow.com/questions/5628077/is-using-proguard-worth-the-trouble