¿Por qué debería deshabilitar ProGuard para vending.billing?

La principal razón / dificultades al usar proguard es el código ofuscante que utiliza la reflexión.

Por ejemplo, cuando se instancia una clase por nombre, como los servicios web, y algunos xml parser hacer, esto no funciona más.

Otra razón por la que la ofuscación no está permitida, pero probablemente no está relacionada con la pregunta:
Las condiciones de licencia como GPL exigen la posibilidad de sustitución de la biblioteca por el usuario final por una versión actualizada de la lib.
Tal lib no se permite entonces ser ofuscado (proguard tiene una opción para los frascos de la biblioteca del sich)

Esta es una muy buena pregunta. Sabemos por qué la ofuscación debe estar deshabilitada para algunas clases, pero esto no responde a la pregunta de por qué debe deshabilitarse para InAppBillingService . Si ha generado InAppBillingService.class , se dará cuenta de que no hay una sola llamada de reflexión, así como ninguna getClass().getName() . Esto significa que la reflexión no se utiliza allí. Las referencias de implementación de IAB generan la clase directamente por nombre, lo que significa que obfuscator no quitará calsses de distribución en el paso de optimización. Por lo tanto, todavía hay "¿por qué es esto un deber?" pregunta.

Mi aplicación ha estado utilizando IAP V3 más de medio año ya con el paquete de factura ofuscado y no hay un solo problema con IAB en absoluto. El único problema potencial que veo es si Android cambia la forma en que genera clases java para interfaces de ayuda. Se empieza a usar la reflexión, entonces tendré que mantener esas clases de ser ofuscado. Pero esto es poco probable que suceda porque potencialmente romperá la codificación en muchas otras aplicaciones usando aidl, también.

Proguard no sólo ofusca las aplicaciones, sino también las optimiza. Mientras que la optimización elimina las clases no referenciadas.

Para evitar la eliminación de las clases de vending tienes que añadir esa línea a tu proguard.cfg