http://developer.android.com/google/play/billing/billing_best_practices.html
注意:如果您使用 Proguard 来混淆您的代码,您必须将以下行添加到您的 Proguard 配置文件中:
-keep class com.android.vending.billing.**
问题是:为什么?!
http://developer.android.com/google/play/billing/billing_best_practices.html
注意:如果您使用 Proguard 来混淆您的代码,您必须将以下行添加到您的 Proguard 配置文件中:
-keep class com.android.vending.billing.**
问题是:为什么?!
这是一个非常好的问题。我们知道为什么必须对某些类禁用混淆,但这并不能回答为什么应该对InAppBillingService
. 如果你 checkout generated InAppBillingService.class
,你会发现没有一个反射调用,也没有任何getClass().getName()
调用。这意味着那里不使用反射。IAB 实现直接按名称引用生成的类,这意味着混淆器不会在优化步骤中删除自动售货类。因此,仍然存在“为什么这是必须的?” 问题。
我的应用程序已经使用 IAP V3 半年多了,其中包含混淆的计费包,而且 IAB 根本没有任何问题。我看到的唯一潜在问题是,如果 Android 改变了它为aidl 接口生成 java 类的方式。它开始使用反射,然后我需要防止这些类被混淆。但这不太可能发生,因为它也可能会破坏许多其他使用aidl的应用程序的编码。
使用 proguard 的主要原因/困难是混淆了使用反射的代码。
例如,当您按名称实例化一个类时,例如 Web 服务,而某些 xml 解析器会这样做,这将不再起作用。
另一个不允许混淆但可能与问题无关的原因:
像 GPL 这样的许可条件要求最终用户可以用更新版本的 lib 替换 lib。
然后不允许混淆这样的库(proguard 有一个用于 sich 库 jar 的选项)
Proguard 不仅可以混淆应用程序,还可以优化它们。在优化它时会删除未引用的类。
为了防止删除自动售货机的类,您必须将该行添加到您的 proguard.cfg