Android developer Guide (9) -- ProGuard

Preface

This chapter describes the developer Guide/Developing/Tools/ProGuard. This chapter describes the obfuscators and version Android3.0 r1 ", welcome to talk with him: "litaojun@gmail.com", thank you again "Jim "! We look forward to your participation in translation of Android related information, contact me over140@gmail.com.

 

Statement

You are welcome to repost, but please keep the original source of the article :)

Blog Garden: http://www.cnblogs.com/

Android Chinese translation group: http://goo.gl/6vJQl

 

Original

Http://developer.android.com/guide/developing/tools/proguard.html

 

Obfuscators(ProGuard)

In this article (In this document)

Enabling ProGuard

Logging ing ProGuard

Decoding Obfuscated Stack Traces

Debugging considerations for published applications

See

ProGuard Manual»

ProGuard ReTrace Manual»

Obfuscators compress, optimize, and confuse code by deleting unused code and renaming classes, fields, and methods with obscure names. The result is a relatively small .apk file, which is difficult to reverse engineer. Therefore, obfuscators are an important protection tool when your applications are sensitive to security (high requirements), for example, when you authorize applications.

Obfuscators are integrated into android build systems, so you do not have to call them manually. At the same time, obfuscators run only when building applications in release mode, so you do not have to deal with obfuscation code when building a program in debug mode. It is optional for the obfuscator to run, but it is recommended.

This document describes how to enable and configure obfuscators, and decode the stack trace information (stack traces) by using the trace (retrace) tool.

 

 

Enable obfuscatorsEnabling ProGuard

After you create an Android project, a proguard. cfg file is automatically created under the root directory of the project. This file defines how obfuscators optimize and confuse your code, so it is very important to know how to customize according to your needs. The default configuration file only covers the general situation, so you may need to edit it as needed. The following content is about how to configure the obfuscator by customizing the obfuscator configuration file.

To enable the obfuscator as part of the Ant or Eclipse build process, you can set the proguard. config attribute in the <project_root>/default. properties file. The path can be an absolute path or a relative path of the Project root directory.

If you want the proguard. cfg file to be in the default location (the root directory of the project), you can specify the location as follows:

Proguard. config = proguard. cfg

Similarly, you can place the file in any location and specify its absolute path.

Proguard. config =/path/to/proguard. cfg

In release mode, you can run ant release or useExport WizardWhen building your application, the build system will automatically check whether the proguard. config attribute is set. If it is set, the producer automatically obfuscation the application bytecode before packaging all the east and west into A. APK file. In the debugging mode, obfuscators are not called, because the debugging will be heavier.

After the obfuscator is run, the output files are:

Dump.txt

The internal structure of all class files in the pai.apk package.

Mapping.txt

Lists the mappings between source code and obfuscated classes, methods, and attribute names. This file is useful for bug reports after construction, because it translates obfuscated stack trace information into classes, methods, and member names in the source code. For more information, view the decoded stack trace information.

Seeds.txt

List unobfuscated classes and members.

Usage.txt

Extract the code from .apk.

These files are stored in the following directory:

L <project_root>/bin/proguard when you use Ant

L <project_root>/proguard when you use Eclipse

Note: These files will be overwritten by the latest files each time they are built in release mode. Therefore, each time you release a program, you must save a copy of these files to prevent obfuscation of bug reports generated during build. For more information about the importance of saving these files, see precautions for program release and debugging.

 

 

Obfuscator Configuration(Processing ing ProGuard)

In some cases, the default configuration of the proguard. cfg file can meet the requirements. However, for obfuscators, it is difficult to make a correct analysis in most cases, and it may be useless to delete it, but it does need the code for the program. Some examples are as follows:

L a class that only references the AndroidManifest. xml file.

L a method called through JNI.

L dynamically referenced attributes and methods.

The default proguard. the cfg file tries to overwrite normal cases, but you may encounter an exception similar to ClassNotFoundException, which occurs when your program accesses a class removed by the obfuscator.

You can add the-keep line in the proguard. cfg file to fix these errors. For example:

-Keep public class <MyClass>

-The Keep settings have many options and considerations. Therefore, we strongly recommend that you read the obfuscators user manual for more configuration information. Particularly useful are the summary and examples of Keep options. In the problem solution section of the obfuscator manual, This section describes other common problems that you may encounter during code obfuscation.

 

 

Decode obfuscated stack trace information(Decoding Obfuscated Stack Traces)

When code is obfuscated and a stack debugging information is output, these methods are confused. Although debugging can be performed, debugging becomes difficult. Fortunately, every time the obfuscator runs, it will be output to the <project_root>/bin/proguard/mapping.txt file, which contains the original class, ing method and attribute names to names after obfuscation.

The retrace. bat script command in Windows or the retrace. sh script command in Linux and Mac OS X can convert the mixed stack debugging information into understandable files. It is stored in the <sdk_root>/tools/proguard/directory. The command syntax for running 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<Stracktrace_file>If the value is specified, the retrace tool reads data from the standard input.

 

Precautions for Debugging published applications (Debugging considerations for published applications)

Save the mapping.txt file of every program that has been provided to the user. You can copy the ing.txt File Created by the repository without warranty to ensure that when you encounter a bug and submit the mixed stack debugging tracing information to you, you can perform debugging to fix the problem. The mapping.txt file of the program will be overwritten every time it is released and constructed, so be sure to save the correct version.

For example, assume that you have released an application and continue to develop and add new features in the new version. Start the obfuscator immediately and create a new version. This operation overwrites the mapping.txt file. A user submits a bug report from the current released version, which contains stack debugging information. You can no longer view the stack information of the user, because the mapping.txt file on the user's local machine does not exist. There are many other scenarios where the ing.txt file is overwritten. Therefore, you must make sure that there is a copy for each version that may need to be debugged.

For example, it is up to you to save the mapping.txt file. For example, you can rename them based on the version and build number, or perform version control together with your source code.

 

 

Related Articles

ProGuard summarizes and obfuscation of problems encountered in Android code and finds getSomething games.

Proguard usage