http://developer.android.com/google/play/billing/billing_best_practices.html
Note: If you use Proguard to obfuscate your code, you must add the following line to your Proguard configuration file:
-keep class com.android.vending.billing.**
The question is: WHY?!
This is a really good question. We know why obfuscation must be disabled for some classes, but this does not answers the question why it should be disabled for InAppBillingService
. If you checkout generated InAppBillingService.class
, you will realise there is no a single reflection call, as well as no any getClass().getName()
calls. This means reflection is not used there. IAB implementation references generated class directly by name, which means obfuscator won't remove vending calsses at optimisation step. Thus, there is still "why is this a must?" question.
My app has been using IAP V3 over half a year already with obfuscated billing package and there is no a single issue with IAB at all. The only potential problem I see is if Android changes the way it generates java classes for aidl interfaces. It is starts to use reflection, then I will need to keep such classes from been obfuscated. But this is unlikely to happen because it will potentially break coding in many other apps using aidl, too.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With