我正在使用最新的Android SDK(4.1),我尝试导出已启用Proguard的签名jar.但是,在反编译优化的APK之后,我注意到我希望内联的方法不是.
我知道Proguard运行是因为代码被正确混淆了.所以为了确认这一点,我在我的Activity中添加了这个方法:
private void testInlining()
{
mConfig = null;
}
这个私有方法在我的活动中只被调用一次,并且因为它是私有的,所以优化器应该非常明显它只被调用一次并且它应该被内联.
文档说明默认情况下启用所有优化,并且Proguard"内联方法很短或只调用一次".
是否有一个特定的标志我应该给Proguard启用内联？
编辑
我的proguard配置文件包含
-optimizationpasses 5
-allowaccessmodification
-overloadaggressively
-repackageclasses ''
-dontskipnonpubliclibraryclasses
编辑
使用后
-whyareyoukeeping class com.templatecompany.templateappname.EntryPointActivity {*;}
我得到了没有内联方法的原因:
[proguard] com.templatecompany.templateappname.EntryPointActivity: void testInlining() (20:21)
[proguard] is invoked by com.templatecompany.templateappname.EntryPointActivity: com.td.media.ivConnection.IvConfig getIvConfig() (14:15)
[proguard] implements com.td.widget.MainActivity: com.td.media.ivConnection.IvConfig getIvConfig()
[proguard] is invoked by com.td.widget.MainActivity: void onCreate(android.os.Bundle) (140:175)
[proguard] implements android.app.Activity: void onCreate(android.os.Bundle)
[proguard] is a library method.
但我不确定testInlining这个方法getIvConfig在另一个方法反过来使用的方法中使用的事实是如何阻止内联testInlining的getIvConfig.
在Android中,ZipAlign用于对齐4字节边界上的资源以加速资源加载:
Android中的资源处理代码可以通过内存映射它们在4字节边界上对齐时有效地访问资源.但是对于未对齐的资源(即当zipalign尚未在apk上运行时),它必须回退到明确地读取它们 - 这更慢并且消耗额外的内存.
运行该工具后,可以使用该命令验证对齐.
zipalign -c -v 4 application.apk
这会生成一个报告并告知是否存在错误.在我的例子中,这个报告表明没有对齐错误,但是第一个数字,我认为它是最终APK中资源的位置,似乎表明某些资源没有在4个字节边界上对齐.
以下是本报告的开头:
Verifying alignment of APP-signed-aligned.apk (4)...
50 META-INF/MANIFEST.MF (OK - compressed)
24245 META-INF/KEYS.SF (OK - compressed)
49830 META-INF/KEYS.DSA (OK - compressed)
50683 AndroidManifest.xml (OK - compressed)
53096 assets/Assets/DB_Normal.db (OK)
595425 assets/Assets/Common/DM/Structures.xml (OK - compressed)
我错过了什么？第一个数字是资源的位置吗？例如,Structures.xml似乎是595425,它不是4个字节的倍数.
我正在使用伟大的 Charles Web 代理做反向代理并调试我的客户端和安全服务器之间的交换。我接受 Charles 证书作为受信任的权威机构，并且在代理模式下使用它时通常工作得很好，问题是当我尝试创建反向代理时。
我正在使用一个外部库，我无法控制该库使用 HttpUrlConnection 并让我指定 URL。按照Charles 文档，我将 URL 设置为https://mybox.test.com:100（请注意，我使用了添加到主机文件中的主机名，而不是 localhost，希望我可以获得有效的证书）。
问题是，作为 Https 验证的一部分，HttpUrlConnection 会根据证书中的主机名（我要连接到的安全站点之一）验证主机名（mybox.test.com，因为它指向我的反向代理）。显然，这不匹配并导致 Caused by: javax.net.ssl.SSLHandshakeException:java.security.cert.CertificateException: No subject alternative DNS name matching localhost found.
我意识到 Charles 无法为 mybox.test.com 生成证书，因为它只侦听特定端口并且不知道 HttpUrlConnection 中使用的 URL。我不明白它如何生成可以接受的正确证书。
我的问题是：是否有更好的方法将反向代理与 Https 结合使用，或者我是否需要禁用主机名和证书验证？