Android Code obfuscation

1. Setting Confusion

Locate the Project.Properties file under engineering

Add Proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt to the file this is the system.

You can also use your own confusing files (so that you can configure some of their own things), to sdk.dir}/tools/proguard/under the copy proguard-android.txt file to the local project

Then set into Proguard.config=proguard-android.txt

Project.Properties file:

[Java]View Plaincopy

• #proguard. Config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
• Proguard.config=proguard-android.txt
• # Project Target.
• Target=android-17

• -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 ========================================

  
  OriginalHttp://developer.android.com/guide/developing/tools/proguard.html
  obfuscation (Proguard)Enabling proguardconfiguring proguarddecoding obfuscated Stack tracesdebugging 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 ProguardWhen 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.
  Source: >  
  

From for notes (Wiz)

Android Code obfuscation