标签:android style class blog code http
当前是有些工具比方apktool,dextojar等是能够对我们android安装包进行反编译,获得源代码的。为了降低被别人破解,导致源代码泄露,程序被别人盗代替码,等等。我们须要对代码进行混淆,android的sdk中为我们提供了ProGrard这个工具,能够对代码进行混淆(通常是用无意义的名字来重命名),以及去除没有使用到的代码,对程序进行优化和压缩,这样能够添加?你想的难度。近期我做的项目,是我去配置的混淆配置,因此研究了一下,这里分享一下。
在项目的project.properties文件里加入?一下代码
proguard.config=proguard.cfg //proguard.cfg为proguard的配置文件
proguard.config=/path/to/proguard.cfg //路径不在项目根文件夹时,填写实际路径
填写这句配置后,在release打包时就会依照我们的配置进行混淆,注意,在我们平时的debug时是不会进行混淆的。
在build.gradle中进行配置
android {
buildTypes {
release {
runProguard true
proguardFiles getDefaultProguardFile(‘proguard-android.txt‘),‘some-other-rules.txt‘
//proguardFile ‘some-other-rules.txt‘ 配置单个文件这样
}
}
}
如上面代码所看到的,我们能够使用runProguard true开启,而且对其配置混淆配置,能够配置多个文件或单个文件。
android的sdk中已经为我们提供了两个默认的配置文件,我们能够拿过来进行使用,proguard-android.txt和proguard-android-optimize.txt。
上面说到android为我们提供了两个默认的配置文件,在当中,我们能够看到他的一些语法。本节进行描写叙述。
保留选项(配置不进行处理的内容)
-keep {Modifier} {class_specification} 保护指定的类文件和类的成员
-keepclassmembers {modifier} {class_specification} 保护指定类的成员,假设此类受到保护他们会保护的更好
-keepclasseswithmembers {class_specification} 保护指定的类和类的成员,但条件是全部指定的类和类成员是要存在。
-keepnames {class_specification} 保护指定的类和类的成员的名称(假设他们不会压缩步骤中删除)
-keepclassmembernames {class_specification} 保护指定的类的成员的名称(假设他们不会压缩步骤中删除)
-keepclasseswithmembernames {class_specification} 保护指定的类和类的成员的名称,假设全部指定的类成员出席(在压缩步骤之后)
-printseeds {filename} 列出类和类的成员-keep选项的清单,标准输出到给定的文件
压缩
-dontshrink 不压缩输入的类文件
-printusage {filename}
-whyareyoukeeping {class_specification}
优化
-dontoptimize 不优化输入的类文件
-assumenosideeffects {class_specification} 优化时如果指定的方法,没有不论什么副作用
-allowaccessmodification 优化时同意訪问并改动有修饰符的类和类的成员
混淆
-dontobfuscate 不混淆输入的类文件
-obfuscationdictionary {filename} 使用给定文件里的keyword作为要混淆方法的名称
-overloadaggressively 混淆时应用侵入式重载
-useuniqueclassmembernames 确定统一的混淆类的成员名称来添加?混淆
-flattenpackagehierarchy {package_name} 又一次包装全部重命名的包并放在给定的单一包中
-repackageclass {package_name} 又一次包装全部重命名的类文件里放在给定的单一包中
-dontusemixedcaseclassnames 混淆时不会产生形形色色的类名
-keepattributes {attribute_name,...} 保护给定的可选属性,比如LineNumberTable, LocalVariableTable, SourceFile, Deprecated, Synthetic, Signature, and InnerClasses.
-renamesourcefileattribute {string} 设置源文件里给定的字符串常量
后面的文件名称,类名,或者包名等能够使用占位符取代
?表示一个字符
能够匹配多个字符,可是假设是一个类,不会匹配其前面的包名
* 能够匹配多个字符,会匹配前面的包名。
在android中在android Manifest文件里的activity,service,provider, receviter,等都不能进行混淆。一些在xml中配置的view也不能进行混淆,android提供的默认配置中都有。
混淆之后,会给我们输出一些文件,在gradle方式下是在<project_dir>/build/proguard/文件夹下,ant是在<project_dir>/bin/proguard文件夹,eclipse构建在<project_dir>/proguard文件夹像。
分别有下面文件:
+ dump.txt 描写叙述apk文件里全部类文件间的内部结构。
+ mapping.txt 列出了原始的类,方法,和字段名与混淆后代码之间的映射。
+ seeds.txt 列出了未被混淆的类和成员
+ usage.txt 列出了从apk中删除的代码
当我们公布的release版本号的程序出现bug时,能够通过以上文件(特别时mapping.txt)文件找到错误原始的位置,进行bug改动。同一时候,可能一開始的proguard配置有错误,也能够通过错误日志,依据这些文件,找到哪些文件不应该混淆,从而改动proguard的配置。
注意:又一次release编译后,这些文件会被覆盖,所以没吃公布程序,最好都保存一份配置文件。
上面说了输出的几个文件,我们在改bug时能够使用,通过mapping.txt,通过映射关系找到相应的类,方法,字段等。
另外Proguard文件里包括retrace脚本,能够将一个被混淆过的堆栈跟踪信息还原成一个可读的信息,window下时retrace.bat,linux和mac是retrace.sh,在<sdk_root>/tools/proguard/目录下。语法为:
retrace.bat|retrace.sh [-verbose] mapping.txt [<stacktrace_file>]
比如:
retrace.bat -verbose mapping.txt obfuscated_trace.txt
假设你没有指定<stacktrace_file>,retrace工具会从标准输入读取。
以下再写一些我在项目中使用到的一些第三方包须要单独配置的混淆配置
-keep class android.net.http.SslError
-keep class android.webkit.**{*;}
-keep class cn.sharesdk.**{*;}
-keep class com.sina.**{*;}
-keep class m.framework.**{*;}
-keepattributes *Annotation*
-keep class sun.misc.Unsafe { *; }
-keep class com.idea.fifaalarmclock.entity.***
-keep class com.google.gson.stream.** { *; }
-keepclassmembers class * {
public <init>(org.json.JSONObject);
}
-keep class com.umeng.**
-keep public class com.idea.fifaalarmclock.app.R$*{
public static final int *;
}
-keep public class com.umeng.fb.ui.ThreadView {
}
-dontwarn com.umeng.**
-dontwarn org.apache.commons.**
-keep public class * extends com.umeng.**
-keep class com.umeng.** {*; }
关于配置方面,我写的不够具体,能够去看參考资料第二条,proguard官方文档。也欢迎大家交流使用遇到的问题和心得。
资料參考:
1.http://proguard.sourceforge.net/
2.http://developer.android.com/tools/help/proguard.html
使用proguard混淆android代码,布布扣,bubuko.com
标签:android style class blog code http
原文地址:http://www.cnblogs.com/blfshiye/p/3796384.html