防反編譯、混淆文件proguard.cfg與proguard-project.txt詳解

在新版本的ADT建立項目時，混碼的文件再也不是proguard.cfg，而是project.properties和proguard-project.txt。

若是須要對項目進行全局混碼，只須要進行一步操做：

將project.properties的中

「#  proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt」的「#」去掉就能夠了。

 

如 果有一些代碼不能被混淆，好比須要加入了so文件，須要調用裏面的方法，那麼調用JNI訪問so文件的方法就不能被混碼。在導出的時候，可能不會報錯。但 是在手機上運行的時候，須要調用so文件的時候，就會報某某方法沒法找到。這個時候就須要用到proguard-project.txt。

 

在老版本中，建立項目的時候，會給出proguard.cfg，可是在的新版中建立項目則不會有任何提示。這個時候須要只要將proguard.cfg的內容加入到proguard-project.txt中，再根據本身的須要進行編輯便可。

 

 

 

 

 

==================proguard.cfg防反編譯方法==================================

To enable ProGuard so that it runs as part of an Ant or Eclipse build, set the proguard.config property in the<project_root>/project.properties file. The path can be an absolute path or a path relative to the project's root.

If you left the proguard.cfg file in its default location (the project's root directory), you can specify its location like this:

proguard.config=proguard.cfg

You can also move the the file to anywhere you 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 Wizard in Eclipse, the build system automatically checks to see if the proguard.config property is set. If it is, ProGuard automatically processes the application's bytecode before packaging everything into an .apk file. Building in debug mode does not invoke ProGuard, because it makes debugging more cumbersome.

 

 

===========【轉】混淆文件proguard.cfg詳解======================================

 

-injars  androidtest.jar【jar包所在地址】

-outjars  out【輸出地址】

-libraryjars    'D:\android-sdk-windows\platforms\android-9\android.jar' 【引用的庫的jar，用於解析injars所指定的jar類】

-optimizationpasses 5

-dontusemixedcaseclassnames 【混淆時不會產生形形色色的類名 】

-dontskipnonpubliclibraryclasses 【指定不去忽略非公共的庫類。 】

-dontpreverify 【不預校驗】

-verbose

-optimizations !code/simplification/arithmetic,!field/*,!class/merging/* 【優化】

-keep public class * extends android.app.Activity　　【不進行混淆保持原樣】

-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>;  【全部方法不進行混淆】

}

-keep public class com.asqw.android{

public void Start(java.lang.String); 【對該方法不進行混淆】

}

-keepclasseswithmembernames class * { 【保護指定的類和類的成員的名稱，若是全部指定的類成員出席（在壓縮步驟以後）】

native <methods>;

}

-keepclasseswithmembers class * { 【保護指定的類和類的成員，但條件是全部指定的類和類成員是要存在。】

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 {【保護指定類的成員，若是此類受到保護他們會保護的更好 】

public void *(android.view.View);

}

-keepclassmembers enum * {

public static **[] values();

public static ** valueOf(java.lang.String);

}

-keep class * implements android.os.Parcelable {【保護指定的類文件和類的成員】

public static final android.os.Parcelable$Creator *;

}

 

 

 

 

 

=====================================常見異常===================================

參考：http://blog.csdn.net/vrix/article/details/7100841

 

加入第三方jar包以後常出現的幾個異常：

proguard returned with error code 1.See console

狀況1：

Proguard returned with error code 1. See console

Error: C:/Documents (系統找不到指定文件)

後來發現是由於將整個工程放到了桌面上，而桌面的目錄是C:/Documents and Settings/Administrator/桌面，在這裏面有空格，而proguard進行發編譯的時候是不容許有空格的

若是換了正確路徑還很差用的話，直接刪除proguard就行了

注意：SDK和程序路徑最好不要有空格符

狀況2：

Proguard returned with error code 1. See console

異常：

java.lang.ArrayIndexOutOfBoundsException

解決辦法：將proguard.cfg中的"-dontpreverify"改爲「-dontoptimize」

參考文章：http://groups.google.com/group/android-developers/browse_thread/thread/eca3b0f5ce6ad00f

 

我把項目中生成的proguard文件夾（此時文件夾是空的）刪掉，而後再從新運行項目，就OK 了。

狀況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 [proguard.ClassPathEntry@106082] (No such file or directory)

[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)

拋出這樣的異常的緣由是第三方jar的引用路徑不對，沒有找到這個須要忽略混淆的jar包。

 

 

 

========================官方文檔翻譯========================================

 

 

原文

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

 

混淆器(ProGuard)

　　在本文中(In this document)

Enabling ProGuard

Configuring ProGuard

Decoding Obfuscated Stack Traces

Debugging considerations for published applications

　　參見

ProGuard Manual ?

ProGuard ReTrace Manual ?

混淆器經過刪除從未用過的代碼和使用晦澀名字重命名類、字段和方法，對代碼進行壓縮，優化和混淆。結果是一個比較小的.apk文件，該文件比較難進行逆向工程。所以，當你的應用程序對安全敏感（要求高），例如當你受權應用程序的時候，混淆器是一種重要的保護手段。

混淆器被集成在android 構建系統中，因此你沒必要手動調用它。同時混淆器僅在發佈模式下進行構建應用程序的時候纔會運行起來，因此在調試模式下構建程序時，你沒必要處理混淆代碼。讓混淆器運行起來是可選擇的，可是推薦選上。

這個文檔描述了怎樣啓用並配置混淆器，以及使用跟蹤（retrace）工具對混淆的堆棧跟蹤信息（stack traces）進行解碼。

 

啓用混淆器Enabling ProGuard

當你新建了一個Android工程以後，一個proguard.cfg文件會在工程的根目錄下自動建立。這個文件定義了混淆器是怎樣優化和混淆你的代碼的，因此懂得怎樣根據你的須要來定製是很是重要的。缺省的配置文件僅覆蓋到了一般狀況，因此根據你的需求，極可能須要編輯它。接下來的內容是關於經過定製混淆器配置文件來對混淆器配置。

爲了讓啓用混淆器做爲Ant或者Eclipse構建過程當中一部分，能夠在<project_root>/default.properties文件中，設置proguard.config屬性。路徑能夠是絕對路徑或者工程根目錄的相對路徑。

若是你讓proguard.cfg文件在缺省位置（工程的根目錄），你能夠像這樣指定位置：

proguard.config=proguard.cfg

    一樣，你能夠把該文件放到任意的位置，並指定它的絕對路徑。

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

當你在發佈模式下，或者經過運行ant release，或者經過使用Eclipse中的Export Wizard構建你的應用程序的時候，構建系統都會自動地去檢查proguard.config屬性是否被設置了。若是被設置了，混淆器在把全部東西打包成.apk文件以前，自動地對應用程序字節碼進行混淆處理。而在調試模式中構建則不會調用混淆器，由於那樣調試會更加繁重。

     運行混淆器以後輸出的文件有：

dump.txt

                  描述.apk包中全部class文件的內部結構。

mapping.txt

列出了源代碼與混淆後的類，方法和屬性名字之間的映射。這個文件對於在構建以後獲得的bug報告是有用的，由於它把混淆的堆棧跟蹤信息反翻譯爲源代碼中的類，方法和成員名字。更多信息，查看解碼混淆過的堆棧跟蹤信息。

seeds.txt

                  列出那些未混淆的類和成員。

usage.txt

                  列出從.apk中剝離的代碼。

這些文件放在如下目錄中：

 

1. <project_root>/bin/proguard 當你使用Ant時

2. <project_root>/proguard 當你使用Eclipse時

 

注意：每次在發佈模式下構建時，這些文件都會被最新的文件覆蓋。因此每次發佈程序時候，爲了反混淆來自構建時產生的bug報告，請保存這些文件的一個拷貝。對於爲何要保存這些文件的重要性的更多信息，請查看程序發佈調試注意事項。

 

 

混淆器配置（proguard config）

某些狀況下，proguard.cfg文件的缺省配置能夠知足需求了。可是，對於混淆器來講，大多數狀況作出正確的分析是困難的，而且它或許會刪除在它看來是無用的，但對於程序來講卻確實須要的代碼。一些例子以下：

 

1. 一個僅引用於AndroidManifest.xml文件的類。

2. 一個經過JNI調用的方法。

3. 動態引用的屬性和方法。

 

缺省的proguard.cfg文件試圖覆蓋普通的狀況，可是你可能碰到相似ClassNotFoundException的異常，這個異常出如今當你的程序去訪問一個被混淆器移除了的類的時候。

你能夠在proguard.cfg文件中添加-keep這一行來修復這些錯誤。例如：

-keep publicclass<MyClass>

-Keep設置有不少可選項和注意地方，因此爲了得到更多關於配置信息，強烈推薦你閱讀混淆器用戶手冊。特別有用的有Keep選項綜述和舉例部分。在混淆器手冊問題解決方案部分，介紹了代碼在混淆過程當中你可能碰到的其餘常見問題。

解碼混淆過的堆棧跟蹤信息（Decoding Obfuscated Stack Traces）

當混淆代碼並輸出了一個堆棧調試信息時，這些方法名字是混淆過的，雖然能夠進行調試，可是調試變得困難。幸運的是，每當混淆器運行時候，它都會輸出到文件<project_root>/bin/proguard/mapping.txt中，該文件包含了從原始類，方法和屬性名字到混淆後名字的映射。

Windows系統中retrace.bat腳本命令或者Linux和Mac OS X系統中retrace.sh腳本命令能把混淆後的堆棧調試信息轉換爲能夠理解的文件。它被放在<sdk_root>/tools/proguard/目錄下。運行retrace工具的命令語法是：

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

例如：

retrace.bat -verbose mapping.txt obfuscated_trace.txt

若是你沒有爲<stracktrace_file>指定值，那麼retrace工具從標準輸入讀取。

 

已發佈應用程序的調試注意事項(Debugging considerations for published applications)

保存好每個已發佈給用戶的程序的mapping.txt文件。經過保存發佈構建版本的mapping.txt文件拷貝，確保當用戶碰到bug，並把混淆後的堆棧調試跟蹤信息提交給你時，你能夠進行調試從而修復問題。程序的mapping.txt文件在每次發佈構建時都會被覆蓋，因此你必定要注意保存正確的版本。

例如，假設你已經發布了一個應用程序並在繼續在新的版本中開發添加新的功能。接着你立刻啓動混淆器並建立一個新的發佈版本。該操做把mapping.txt文件覆蓋了。一個用戶提交了來自當前發佈版本的bug報告，該報告包含了堆棧調試信息。你不再能對用戶的堆棧信息進行調試了，由於這個對應用戶本機上版本的mapping.txt文件不存在了。其餘覆蓋mapping.txt文件的狀況還有不少，因此對於每個可能須要調試的版本，你都要確保有一份拷貝。

如何保存mapping.txt文件由你決定。例如，你能夠根據版本和構建號來重命名它們，或者連同你的源代碼進行版本控制。