Role, use, and Bug Analysis of proguard (reproduced)

Role, use, and Bug Analysis of proguard

This article mainly describes the functions, usage, and Bug Analysis of proguard.
1. Role of proguard
By deleting useless code, proguard renames the class name, method name, and attribute name in the Code with obscure names to achieve code obfuscation, compression, and optimization, similar to JavaScript obfuscation and compression.
Compression and optimization make the compiled APK package smaller.
Obfuscation ensures that the code is difficult to understand after being decompiled and prevents reverse engineering. This is also one of the major reasons we need proguard before releasing an application.

 

2. Use of proguard
(1). system applications:
Add the following content to the Android. mk file in the root directory of the project:

XHTML

12	Local_proguard_flag_files: = proguard. cfglocal_proguard_enabled: = full

In this way, the application does not need to set the proguard configuration file separately. During system compilation, the system's unified proguard will be used. CFG performs proguard on the application, and the system proguard. CFG is located in the system root directory \ build \ core.

 

(2). Non-system applications:
A. Turn on proguard.
Configure proguard in the project. properties file under the project root directory and add the following code:

XHTML

1	Proguard. Config = proguard. cfg

In this way, before packaging the APK in release mode, proguard uses proguard. cfg as the rule to process the application bytecode. Section C of the release mode will be introduced.

 

B. compile your own proguard config file.
By default, all codes are obfuscated. If you need some obfuscation, you can modify the proguard. cfg file by yourself.
The syntax and standard configuration of proguard config are as follows: proguard syntax and common proguard. cfg code snippet

Note that the following types cannot be confused:
(1) class used for reflection
(2) classes configured in androidmanifest (subclasses of activity, service, and framework classes will not be confused by default)
(3) classes called in JNI

 

C. Introduction to running proguard and its generated files
When you package an APK in release mode, proguard is automatically run. The release mode here refersAnt releaseCommand orEclipse project-> Android tools-> export signed (unsigned) Application PackageGenerate an APK. In debug mode, proguard is not called for faster debugging.

 

If the ant command is used to package the APK, The proguard information file is saved in the <project_root>/bin/proguard folder. If you use the eclipse Export command to package the APK, it is saved in the <project_root>/proguard folder. It contains the following files:

Mapping.txtIndicates the code comparison table before and after obfuscation. This file is very important. If your code is uploaded to the bug, the logprompt indicates the code behind the Code. If you want to locate the code, you can use mapping.txt to push back the code.
Dump.txtDescribes the internal structure of all class files in the APK.
Seeds.txtLists unobfuscated classes and members.
Usage.txtLists the codes that are deleted from the source code and do not exist in the APK.

For some content of mapping.txt and comparison of codes before and after obfuscation:

We can see that after obfuscation, most codes are abcdefg ..

 

Note:Maintain the habit of mapping.txt.The proguardwill overwrite the original file at each run time, so that the mapping.txt can be saved for each release, so that logs can be called up for troubleshooting when a problem occurs in this version. Mapping.txt can be saved or put into code version control based on the version number or release time.

 

D. Check whether proguard is successful

You can check whether proguard is successful by decompiling the APK. If the code is successful, it will be similar to the above. Most class names and member names are like A. B. C .... For more information about decompilation, see Android APK decompilation.

 

3. Bug Analysis after proguard Obfuscation
(1) code bug
After obfuscation, all codes in the bug prompt information are post-obfuscation codes, Class A. B. C ..., If the mapping.txt file is used for troubleshooting, The mapping.txt file should be used to reverse push the corresponding code segment in the actual code to solve the problem.
PS: $ in the obfuscated code indicates an anonymous internal class, which is outclassname $1 and outclassname $2 in sequence.

 

(2) bugs caused by Obfuscation
Applications may cause bugs due to obfuscation of code that should not be obfuscated by proguard, including classnotfoundexception and badparcelableexception.
For classnotfoundexception, find a class in the ing.txt file and do not confuse it in proguard. cfg.

Java

1	-Keep class packagename. classname {*;}

 

For Android. OS. badparcelableexception: parcelable protocol requires a parcelable. creator object called creator, add in proguard. cfg

Java

123	-Keep class * implements Android. OS. parcelable {public static final Android. OS. parcelable $ creator *;}

 

For Android. Support. V4 can't find superclass or interface, can't find referenced method, add in proguard. cfg

Java

1234	-Libraryjars libs/android-support-v4.jar-dontwarn for Android. support. v4. **-keep class android. support. v4. ** {*;}-keep interface android. support. v4.app. **{*;}

Other issues after proguard obfuscation are visible: http://proguard.sourceforge.net/index.html#manual/troubleshooting.html