如何在Google Play Billing Library 4中混淆Purchase与SkuDetails类

先明确两个不可行方案 #

• 直接混淆官方Purchase/SkuDetails类：这两个是Billing库对外暴露的公共final类，你项目的ProGuard规则默认只会混淆你自己的业务代码，不会修改第三方SDK的公共类名，否则会导致SDK调用直接崩溃。
• 自定义类替换/继承/重写官方类：两个类都是final修饰，无法继承；且Billing库的所有回调、支付启动方法都强依赖官方类的实例，你自己实现的类传入SDK会直接报错，这条路走不通。

可行的优化方案 #

1. 做中间桥接层，销毁官方类实例的长期持有 #

• 不要直接在业务代码中实现官方的PurchasesUpdatedListener、SkuDetailsResponseListener等回调接口，单独写一层无业务逻辑的中转层，回调触发后立刻把Purchase/SkuDetails里的所有字段提取出来，转换成你自己定义的、完全混淆的POJO类，官方类的实例用完立刻释放，不要在内存中长期留存。
• 不要存储SkuDetails实例，只存查询到的Sku对应的原始JSON字符串，需要调用launchBillingFlow启动支付时，再临时通过new SkuDetails(skuJson)构造实例，用完立即销毁，大幅降低内存中可被跟踪的目标对象数量。

2. 优化ProGuard混淆规则 #

• 所有你自己编写的支付相关类、方法、字段，不要加任何-keep规则，确保全部被混淆，类名、方法名统一用无意义的乱码字典，不要出现任何和pay、billing、purchase、sku、vip、premium相关的明文字面量。
• 开启-allowaccessmodification、-optimizationpasses 5等优化选项，尽可能抹除代码结构特征，让反编译后的代码可读性降到最低。

3. 拆分隐藏支付校验链路 #

• 不要在回调方法内直接做购买状态校验、权限解锁逻辑。把Purchase里的purchaseState、purchaseToken、signature等字段全部拆成基础类型（字符串、整型）参数，传到名字完全和支付无关的混淆工具类中做校验，比如用看起来像是处理字符串、存储的类来做签名校验、状态判断，破解者即使定位到回调方法，也很难跟踪到核心校验逻辑。
• 所有和支付相关的字符串常量（包括Sku ID、公钥片段、状态判断用的标记值）全部做加密存储，运行时才解密使用，避免破解者通过字符串搜索定位逻辑。

4. 无后端场景额外防欺诈补充 #

• 必须做官方签名校验：用Google Play Console拿到的公钥验证Purchase返回的签名，公钥不要明文存，拆成多个片段存在不同的类、资源文件中，运行时拼接解密，防止破解者直接替换公钥绕过校验。
• 多加分散的暗桩校验：不要只在启动、回调处做一次购买校验，在付费功能的多个使用节点、应用生命周期的不同阶段都插入轻量校验逻辑，只要有一处校验不通过就锁付费功能，大幅提升破解需要找到的校验点数量。

内容的提问来源于stack exchange，提问作者mavrosxristoforos