Reference Document: http://blog.csdn.net/xueyepiaoling/article/details/8202359
http://glblong.blog.51cto.com/3058613/1263969
When creating a project in a new version of ADT, the mixed files are no longer proguard.cfg, but Project.Properties and Proguard-project.txt.
If you need to make a global mix of items, you only need to do one step:
The project.properties in the
The "#" of "# Proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt" will be removed.
If some code can not be confused, such as the need to add the so file, need to call the inside of the method, then call JNI Access so file method can not be mixed code. When exporting, you may not get an error. But when running on the phone, you need to call so file, it will be reported that such a method cannot be found. We need to use proguard-project.txt at this time.
In the old version, when the project was created, Proguard.cfg was given, but the new version created the project without any hint. This time you need to add proguard.cfg content to the Proguard-project.txt, and then edit according to your own needs.
==================proguard.cfg Anti-================================== compilation method
To enable Proguard-so-it runs as part of a Ant or Eclipse build, set the property in the proguard.config
<project_root>/project.properties
file. The path can be a absolute path or a path relative to the project ' s root.
If you left proguard.cfg
the file under its default location (the project's root directory), you can specify it location like this:
Proguard.config=proguard.cfg
You can also move the "file to anywhere" want, and specify the absolute path to it:
Proguard.config=/path/to/proguard.cfg
When you build your application in release mode, either by running ant release
or by using the " Export" Wizardin Eclipse, The build system automatically checks to see if the property is proguard.config
set. If it is, Proguard automatically processes the application ' s bytecode before packaging everything to an .apk
file. Building in debug mode does not invoke Proguard, because it makes debugging more cumbersome.
======================= confusing file proguard.cfg detailed ======================================
-injars Androidtest.jar "jar Package Address"
-outjars out "Output address"
The jar of the library referenced by-libraryjars ' D:\android-sdk-windows\platforms\android-9\android.jar ', used to parse the jar class specified by Injars "
-optimizationpasses 5
-dontusemixedcaseclassnames "does not produce a variety of class names when confused"
-dontskipnonpubliclibraryclasses "Specifies that non-public library classes are not ignored. 】
-dontpreverify "No pre-check"
-verbose
-optimizations!code/simplification/arithmetic,!field/*,!class/merging/* "Optimization"
-keep public class * extends Android.app.Activity "Do not confuse and remain as is"
-keep public class * extends Android.app.Application
-keep public class * extends Android.app.Service
-keep public class * extends Android.content.BroadcastReceiver
-keep public class * extends Android.content.ContentProvider
-keep public class * extends Android.app.backup.BackupAgentHelper
-keep public class * extends Android.preference.Preference
-keep public class Com.android.vending.licensing.ILicensingService
-keep Public Abstract Interface com.asqw.android.listener{
Public protected <methods>; "All methods are not confused"
}
-keep public class com.asqw.android{
public void Start (java.lang.String); "No confusion with this method"
}
-keepclasseswithmembernames class * {"protects the name of a member of a specified class and class if all the specified class members are present (after the compression step)"
Native <methods>;
}
-keepclasseswithmembers class * {"Protects the members of the specified class and class, but the condition is that all specified classes and class members are to be present." 】
Public <init> (Android.content.Context, Android.util.AttributeSet);
}
-keepclasseswithmembers class * {
Public <init> (Android.content.Context, Android.util.AttributeSet, int.);
}
-keepclassmembers class * extends Android.app.Activity {"Protects members of a specified class if this class is protected they will be better protected"
public void * (Android.view.View);
}
-keepclassmembers enum * {
public static **[] values ();
public static * * VALUEOF (java.lang.String);
}
-keep class * Implements Android.os.Parcelable {"Protection of members of specified class files and classes"
public static final Android.os.parcelable$creator *;
}
===================================== Common anomalies ===================================
Reference: http://blog.csdn.net/vrix/article/details/7100841
Several exceptions that often occur after adding a third-party jar package:
Proguard returned with error code 1.See console
Scenario 1:
Proguard returned with error code 1. See console
Error:c:/documents (the system cannot find the specified file)
Later found because the entire project was put on the desktop, and the desktop directory is c:/documents and settings/administrator/desktop, in which there are spaces, and proguard to compile the time is not allowed to have spaces
If the correct path is not good enough, delete Proguard directly.
Note: The SDK and program paths are best not to have whitespace
Scenario 2:
Proguard returned with error code 1. See console
Abnormal:
Java.lang.ArrayIndexOutOfBoundsException
Workaround: Change "-dontpreverify" in Proguard.cfg to "-dontoptimize"
Reference article: http://groups.google.com/group/android-developers/browse_thread/thread/eca3b0f5ce6ad00f
I delete the Proguard folder (which is empty at this time) in the project and then run the project again, OK.
Scenario 3:
[2011-10-21 13:22:32-zmksmarket_build_v1.0] Proguard returned with error code 1. See console
[2011-10-21 13:22:32-zmksmarket_build_v1.0] java.io.IOException:Can ' t read [[email protected]] (No such file or Directo Ry
[2011-10-21 13:22:32-zmksmarket_build_v1.0]
At Proguard. Inputreader.readinput (inputreader.java:230)
[2011-10-21 13:22:32-zmksmarket_build_v1.0]
At Proguard. Inputreader.readinput (inputreader.java:200)
[2011-10-21 13:22:32-zmksmarket_build_v1.0]
At Proguard. Inputreader.readinput (inputreader.java:178)
[2011-10-21 13:22:32-zmksmarket_build_v1.0]
At Proguard. Inputreader.execute (inputreader.java:100)
[2011-10-21 13:22:32-zmksmarket_build_v1.0]
At Proguard. Proguard.readinput (proguard.java:195)
[2011-10-21 13:22:32-zmksmarket_build_v1.0]
At Proguard. Proguard.execute (proguard.java:78)
[2011-10-21 13:22:32-zmksmarket_build_v1.0]
At Proguard. Proguard.main (proguard.java:499)
The reason for throwing such an exception is that the reference path of the third-party jar is incorrect, and the jar package that needs to be ignored is not found.
======================== Official Document Translation =======================================
Original
Http://developer.android.com/guide/developing/tools/proguard.html
Obfuscation (Proguard)
In this document
Enabling Proguard
Configuring Proguard
Decoding obfuscated Stack traces
Debugging Considerations for Published applications
See
Proguard Manual?
Proguard Retrace Manual?
The obfuscation compresses, optimizes, and confuses code by removing code that has never been used and renaming classes, fields, and methods with obscure names. The result is a smaller. apk file, which is more difficult to reverse engineer. Therefore, when your application is sensitive to security (high demand), such as when you authorize an application, the obfuscation is an important protection tool.
The obfuscation is integrated into the Android build system, so you don't have to call it manually. The obfuscation will only run when the application is built in release mode, so you don't have to deal with confusing code when building the program in debug mode. Making the obfuscation run is optional, but recommended.
This document describes how to enable and configure the obfuscation, and use the Trace (retrace) tool to decode the confusing stack trace information (stack traces).
Enable obfuscation enabling Proguard
When you create a new Android project, a proguard.cfg file is created automatically in the project's root directory. This file defines how the obfuscation optimizes and confuses your code, so it's important to know how to customize it to your needs. The default profile only covers the usual situation, so you might want to edit it depending on your needs. The next step is to configure the obfuscation by customizing the obfuscation configuration file.
In order to enable the obfuscation as part of the ant or Eclipse build process, you can set the Proguard.config property in the <project_root>/default.properties file. The path can be either an absolute path or a relative path to the project root directory.
If you let the Proguard.cfg file in the default location (the project's root directory), you can specify the location like this:
Proguard.config=proguard.cfg
Again, you can put the file in any location and specify its absolute path.
Proguard.config=/path/to/proguard.cfg
When you build your application in release mode, or by running ant release, or by using the Export Wizard in Eclipse, the build system automatically checks to see if the Proguard.config property is set. If set, the obfuscation automatically confuses the application bytecode before it packs everything into an. apk file. Building in debug mode does not call the obfuscation, because that makes debugging more onerous.
Files that are output after running the obfuscation are:
Dump.txt
Describes the internal structure of all class files in the. apk package.
Mapping.txt
Lists the mappings between the source code and the Obfuscated class, method, and property name. This file is useful for bug reports that are made after the build, because it translates the confusing stack trace information into classes, methods, and member names in the source code. For more information, see Decoding the obfuscated stack trace information.
Seeds.txt
Lists the classes and members that are not confused.
Usage.txt
Lists the code stripped from the. apk.
These files are placed in the following directory:
<project_root>/bin/proguard When you use Ant
<project_root>/proguard When you use eclipse
Note: These files are overwritten by the latest files each time they are built in release mode. So every time you publish a program, save a copy of these files in order to counter-confuse bug reports generated from the build. For more information on why you should save the importance of these files, see the program release debugging considerations.
obfuscation configuration (proguard config)
In some cases, the default configuration of the Proguard.cfg file can meet the requirements. However, for a obfuscation, it is difficult to make the right analysis in most cases, and it may remove code that it seems to be useless, but really needs for the program. Some examples are as follows:
A class that references only the Androidmanifest.xml file.
A method that is called through JNI.
Properties and methods for dynamically referencing.
The default proguard.cfg file tries to overwrite the normal situation, but you may encounter an exception similar to ClassNotFoundException, which occurs when your program accesses a class that is removed by the obfuscation.
You can fix these errors by adding the-keep line to the Proguard.cfg file. For example:
-keep publicclass<myclass>
-keep settings have a lot of options and attention places, so in order to get more information about the configuration, it is highly recommended that you read the obfuscation user manual. Particularly useful are the Keep Options overview and Examples section. In the Problem Resolution section of the obfuscation manual, you'll find other common issues that your code may encounter during the obfuscation process.
decode the obfuscated stack trace information (decoding obfuscated stack traces)
When confusing the code and outputting a stack debug message, the names of these methods are confusing, although debugging can be difficult. Fortunately, whenever the obfuscation runs, it is output to the file <project_root>/bin/proguard/mapping.txt, which contains mappings from the original class, method, and property name to the obfuscated name.
The Retrace.bat script commands in Windows systems, or retrace.sh script commands in Linux and Mac OS x systems, can transform the confusing stack debug information into understandable files. It is placed under 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 specify a value for <stracktrace_file> , then the retrace tool reads from the standard input.
Debug Considerations for published applications (debugging Considerations for published applications)
Save the Mapping.txt file for each program that has been published to the user. By saving a copy of the Mapping.txt file of the release build, you can debug to fix the problem when the user encounters a bug and submits the confused stack debug trace information to you. The program's Mapping.txt file will be overwritten every time the release is built, so be sure to keep the correct version in mind.
For example, suppose you have published an application and continue to develop new features in the new version. Then you immediately start the obfuscation and create a new release version. This action overwrites the Mapping.txt file. A user submits a bug report from the current release version that contains the stack debug information. You can no longer debug the user's stack information because the Mapping.txt file that corresponds to the user's native version does not exist. There are many more cases of overwriting mapping.txt files, so you have to make sure you have a copy of each version that you might need to debug.
How to save the Mapping.txt file is up to you. For example, you can rename them based on the version and build number, or with your source code to version control.
Android confuses files Project.Properties and Proguard-project.txt