java – 如何使用ProGuard进行模糊处理,但在测试时保持名称可读？

TL; DR

跳转到Implementation / details部分,将这两个Gradle / Groovy代码块复制到Android子项目的build.gradle文件中.

的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中,但什么时候停止了任何人？！