Android Billing Library 5.0订阅功能特性使用疑问

同订阅产品下base plan/offer购买拦截问题 #

生效状态的同产品订阅无法直接购买其他base plan/offer，是调用逻辑错误，不是系统不支持crossgrade。

• Google Play Console中配置的base plan兼容转换规则，仅在走订阅更新流程时生效。如果调用购买接口时未传入原订阅的购买凭证，系统会判定为重复购买同产品，直接发起拦截，和后台的转换配置无关。
• 正确的crossgrade调用方式：构建BillingFlowParams时，通过setSubscriptionUpdateParams()传入当前生效订阅的purchaseToken，同时指定符合业务需求的proration mode（差价折算模式），即可在订阅正常生效状态下完成同产品不同base plan/offer的转换。
• 测试中出现的「取消订阅后无需等周期结束即可购买其他offer」现象，是因为订阅取消后自动续期状态变为关闭，系统的重复购买拦截逻辑会放开，但此时走的是普通新购流程，不是官方定义的crossgrade，原订阅剩余时长不会自动折算，会直接被新订阅覆盖，不符合正常转换的业务预期。

upgrade offer资格、新offer查询延迟问题 #

这两个表现都是Billing Library的设计逻辑，不是配置错误。

• queryProductDetailsAsync接口不会做用户订阅资格校验，所有配置在后台的offer（包括标记为upgrade、crossgrade资格要求的offer）都会全量返回给客户端，和用户当前是否有生效订阅无关。Google不会在客户端侧做资格拦截，校验逻辑必须由开发者自行实现：需要在展示offer、发起购买前，先通过服务端查询用户的生效订阅列表，判断用户是否满足offer对应的资格要求，不符合条件的offer直接过滤，不展示给用户，同时拦截对应的购买请求。
• 新创建/修改的offer需要数小时才能查询到，是Google Play的多层缓存机制导致：配置提交后首先要在Google全球服务节点同步，之后Play Store客户端本地还有最长24小时的商品缓存。测试阶段可以通过清除Play Store应用数据、在Play内部测试工具中手动触发缓存刷新来缩短等待时间；正式环境下配置发布后建议预留24小时同步窗口，不需要额外做兼容处理。

对接核心检查点 #

• 所有同产品、跨产品的订阅升降级、交叉转换，必须走订阅更新流程，传入旧订阅purchaseToken，禁止走普通新购接口
• 所有带用户身份、历史订阅要求的offer，资格校验逻辑必须由业务侧自行实现，不可依赖Billing库的返回结果做资格判断
• 订阅相关配置修改后不要立即做全量推送，预留足够的缓存同步时间

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