微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

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

我正在使用我的应用程序进行预发布阶段,我开始编译发布版本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.jb51.cc/android/431256.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐