#1: 作者: Caribou, 時間: 2015-3-10 14:32

The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer. Because ProGuard makes your application harder to reverse engineer, it is important that you use it when your application utilizes features that are sensitive to security like when you are Licensing Your Applications.

ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not have to deal with obfuscated code when you build your application in debug mode. Having ProGuard run is completely optional, but highly recommended.

#2: 作者: Caribou, 時間: 2015-3-10 17:35

Decoding Obfuscated Stack Traces

When your obfuscated code outputs a stack trace, the method names are obfuscated, which makes debugging hard, if not impossible. Fortunately, whenever ProGuard runs, it outputs a <project_root>/bin/proguard/mapping.txt file, which shows you the original class, method, and field names mapped to their obfuscated names.

The retrace.bat script on Windows or the retrace.sh script on Linux or Mac OS X can convert an obfuscated stack trace to a readable one. It is located in the <sdk_root>/tools/proguard/ directory. The syntax for executing the retrace tool is:

retrace.bat|retrace.sh [-verbose] mapping.txt [<stacktrace_file>]

For example:

retrace.bat -verbose mapping.txt obfuscated_trace.txt

If you do not specify a value for <stacktrace_file>, the retrace tool reads from standard input.

#3: 作者: Caribou, 時間: 2015-3-10 17:36

Debugging considerations for published applications

Save the mapping.txt file for every release that you publish to your users. By retaining a copy of the mapping.txt file for each release build, you ensure that you can debug a problem if a user encounters a bug and submits an obfuscated stack trace. A project's mapping.txt file is overwritten every time you do a release build, so you must be careful about saving the versions that you need.

For example, say you publish an application and continue developing new features of the application for a new version. You then do a release build using ProGuard soon after. The build overwrites the previous mapping.txt file. A user submits a bug report containing a stack trace from the application that is currently published. You no longer have a way of debugging the user's stack trace, because the mapping.txt file associated with the version on the user's device is gone. There are other situations where your mapping.txt file can be overwritten, so ensure that you save a copy for every release that you anticipate you have to debug.Debugging considerations for published applications

Save the mapping.txt file for every release that you publish to your users. By retaining a copy of the mapping.txt file for each release build, you ensure that you can debug a problem if a user encounters a bug and submits an obfuscated stack trace. A project's mapping.txt file is overwritten every time you do a release build, so you must be careful about saving the versions that you need.

For example, say you publish an application and continue developing new features of the application for a new version. You then do a release build using ProGuard soon after. The build overwrites the previous mapping.txt file. A user submits a bug report containing a stack trace from the application that is currently published. You no longer have a way of debugging the user's stack trace, because the mapping.txt file associated with the version on the user's device is gone. There are other situations where your mapping.txt file can be overwritten, so ensure that you save a copy for every release that you anticipate you have to debug.