我正在使用我的应用程序进行预发布阶段,我开始编译发布版本assembleRelease而不是assembleDebug.然而,混淆破坏了事情,很难破译什么是什么.调试几乎是不可能的,即使行号保持变量类是不可读的.虽然发布版本不稳定但我想让混淆不那么痛苦,但它应该仍然表现得像完全混淆一样.
通常,ProGuarded版本会转换名称
net.twisterrob.app.pack.MyClass
至
b.a.c.b.a
反射和Android布局/菜单资源可以打破,如果他们遇到我们没有保留名称的类.
对于预发布测试来说,能够对代码进行模糊处理会非常有用,但“不是那么多”,比如从
net.twisterrob.app.pack.MyClass
至
net.twisterrob.app.pack.myclass // or n.t.a.p.MC or anything in between :)
proguard -dontobfuscate当然有帮助,但它会使所有破碎的东西再次起作用,因为类名是正确的.
我正在寻找的东西将打破完全混淆会破坏的东西,但同时很容易弄清楚什么是没有使用mapping.txt,因为名称是人类可读的.
我在http://proguard.sourceforge.net/manual/usage.html#obfuscationoptions左右看,但 – *字典选项似乎没有这样做.
我可以自己生成一个重命名文件(它只是运行所有类并给它们一个toLowerCase或其他东西)：
net.twisterrob.app.pack.MyClassA -> myclassa
net.twisterrob.app.pack.MyClassB -> myclassb
那么问题是如何将这样的文件提供给ProGuard以及格式是什么？
-applymapping.
TL; DR
跳转到Implementation / details部分,将这两个Gradle / Groovy代码块复制到Android子项目的build.gradle文件中.
的mapping.txt
mapping.txt的格式非常简单：
full.pack.age.Class -> obf.usc.ate.d:
Type mField -> mObfusc
#:#:Type method(Arg,s) -> methObfusc
kept.Class -> kept.Class:
Type mKept -> mKept
#:#:Type kept() -> kept
收缩的类和成员根本没有列出.因此,所有可用的信息,如果我可以生成相同或转换它,那么成功的机会很大.
解决方案1：转储所有类[失败]
我试图根据传递给proguard(-injars)的当前类路径生成输入mapping.txt.我在URLClassLoader中加载了所有类,其中包含所有程序jar和libraryjars(例如,解析超类).然后遍历每个类和每个声明的成员并输出我希望使用的名称.
这有一个很大的问题：这个解决方案包含了应用程序中每个可重命名的东西的混淆名称.这里的问题是-applymapping从字面上理解并尝试在输入映射文件中应用所有映射,忽略-keep规则,从而导致有关冲突重命名的警告.所以我放弃了这条路,因为我不想复制proguard配置,也不想自己实现proguard配置解析器.
解决方案2：运行proguardRelease两次[Failed]
基于上面的失败,我想到了另一种解决方案,它将利用所有配置并保持存在.流程如下：
>让proguardRelease做它的工作
这会输出source mapping.txt
>将mapping.txt转换为新文件
>复制proguardRelease gradle任务并使用转换后的映射运行它
这个问题是复制整个任务真的很复杂,包括所有的输入,输出,doLast,doFirst,@ TaskAction等等……我实际上已经开始了这条路线,但它很快加入了第三个解决方案.
解决方案3：使用proguardRelease的输出[success]
在尝试复制整个任务并分析proguard / android插件代码时,我意识到只是模拟proguardRelease再次做什么会更容易.这是最后的流程：
>让proguardRelease做它的工作
这会输出source mapping.txt
>将mapping.txt转换为新文件
>使用相同的配置再次运行proguard,
但这次使用我的映射文件进行重命名
结果就是我想要的：
(例如,模式是< package> .__< class> __.__< field> __,其中类和字段名称具有倒置的大小写)
java.lang.NullPointerException: Cannot find actionView! Is it declared in XML and kept in proguard?
at net.twisterrob.android.utils.tools.__aNDROIDtOOLS__.__PREPAREsEARCH__(AndroidTools.java:533)
at net.twisterrob.inventory.android.activity.MainActivity.onCreateOptionsMenu(MainActivity.java:181)
at android.app.Activity.onCreatePanelMenu(Activity.java:2625)
at android.support.v4.app.__fRAGMENTaCTIVITY__.onCreatePanelMenu(FragmentActivity.java:277)
at android.support.v7.internal.view.__wINDOWcALLBACKwRAPPER__.onCreatePanelMenu(WindowCallbackWrapper.java:84)
at android.support.v7.app.__aPPcOMPATdELEGATEiMPLbASE$aPPcOMPATwINDOWcALLBACK__.onCreatePanelMenu(AppCompatDelegateImplBase.java:251)
at android.support.v7.app.__aPPcOMPATdELEGATEiMPLv7__.__PREPAREpANEL__(AppCompatDelegateImplV7.java:1089)
at android.support.v7.app.__aPPcOMPATdELEGATEiMPLv7__.__DOiNVALIDATEpANELmENU__(AppCompatDelegateImplV7.java:1374)
at android.support.v7.app.__aPPcOMPATdELEGATEiMPLv7__.__ACCESS$100__(AppCompatDelegateImplV7.java:89)
at android.support.v7.app.__aPPcOMPATdELEGATEiMPLv7$1__.run(AppCompatDelegateImplV7.java:123)
at android.os.Handler.handleCallback(Handler.java:733)
或者注意下面的下划线：
实施/细节
我试图让它尽可能简单,同时保持最大的灵活性.
我把它称之为“模糊”,因为它正在取消正确的混淆,但仍然考虑了反射方面的混淆.
我实施了一些警卫,因为第二轮做了一些假设.很明显,如果没有混淆,就没有必要进行模糊处理.如果关闭debuging,那么解开(并且可能会被意外释放)几乎没有意义,因为启动会帮助大多数IDE内部.如果应用程序经过测试和混淆,AndroidProguardTask的内部使用映射文件,我现在不想处理它.
所以我继续创建了一个无需任务的任务,它完成了转换并运行了proguard.遗憾的是,proguard配置没有暴露在proguard.gradle.ProguardTask中,但什么时候停止了任何人？！ 原文链接：https://www.f2er.com/android/431256.html
