android proguard,跳过jar
我想知道是否可以在 proguard 中跳过 jar,这样就不会混淆它们...我正在尝试使用以下命令来做到这一点:-libraryjars myjar.jar 但我的代码一直存在问题..
我我正在尝试导出一个具有适用于 Android 的 javamail api 的项目,该项目应该使用 imaps 协议检索我的交换电子邮件...
我正在使用信任管理器来通过证书验证(因为我的 exc 服务器上有自签名证书) )。如果我编译并运行应用程序而不导出它,则一切正常。如果我导出应用程序,我会收到无效证书错误。
在我的活动中,我在 Property 对象上传递 SSLSocketFactory (跳过证书验证的那个):
props.setProperty("mail.store.protocol", "imaps");
props.setProperty("mail.imaps.socketFactory.class", "mail.utils.DummySSLSocketFactory");
所以我认为问题可能出在 javamail jar 中的某个地方,但我不知道如何让 jar 中的所有类被跳过通过proguard...
I want to know if it is possible to skip jars in proguard so that it don't obfuscate them... I am trying to do that with this comand: -libraryjars myjar.jar but I keep having problems with my code..
I am trying to export a project that has javamail api for android and the project is supposed to retreive my exchange emails using imaps protocol...
I am using a trust manager to pass the certificate validation (because I have self signed certificate on my exc server). If I compile and run the app without exporting it, everything works fine. If I export the app I am getting the invalid certificate error.
In my activity I pass the SSLSocketFactory (the one that skips the cert validation) on a Property object :
props.setProperty("mail.store.protocol", "imaps");
props.setProperty("mail.imaps.socketFactory.class", "mail.utils.DummySSLSocketFactory");
So I think the problem could be somewhere in the javamail jar but I don't know how to let all classes from the jar to be skipped by proguard...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
在一般的 ProGuard 配置中,指定 -libraryjars 确实是首选解决方案。
在 Android 构建脚本中,libs 目录中的 jar 已经自动添加为 -injars,这使得这不太方便。您仍然可以指定保留所有代码,例如库中的所有公共类、字段和方法:
您可以通过仅保留相关类来细化配置,例如
在不知道库的内部实现的情况下,这种细化将可能需要一些实验。
In a general ProGuard configuration, specifying -libraryjars would be the preferred solution indeed.
In the Android build script, jars in the libs directory are already added automatically as -injars, which makes this less convenient. You can still specify to preserve all code though, e.g. all public classes, fields, and methods in the library:
You may be able to refine the configuration by only keeping relevant classes, e.g.
Without knowing the internal implementation of the library, this refinement will probably require some experimentation.