Android 应用内订阅支付调用 launchBillingFlow() 后无响应，根本原因在于未为 ProductDetailsParams.Builder 显式设置 offerToken —— 即使使用默认价格方案，也必须传入非 null 字符串（如空字符串 ""），否则构建器会静默阻塞。
android 应用内订阅支付调用 `launchbillingflow()` 后无响应，根本原因在于未为 `productdetailsparams.builder` 显式设置 `offertoken` —— 即使使用默认价格方案，也必须传入非 null 字符串（如空字符串 `""`），否则构建器会静默阻塞。
在 Android Billing Library 5.0+ 中，订阅型商品（ProductType.SUBS）的购买流程要求严格区分定价方案（offers），即使你仅配置了基础订阅（即“默认价格”），Google Play 仍会为其生成一个隐式 offerToken。而 BillingFlowParams.ProductDetailsParams.Builder 在构建时若完全未调用 setOfferToken()，将导致内部状态异常，表现为：
- launchBillingFlow() 调用后无任何日志、无弹窗、无回调、无异常抛出；
- 线程看似“卡住”，实则 Builder 构建失败并静默返回无效参数，致使 BillingClient 拒绝发起支付流程。
✅ 正确做法是：无论是否启用自定义定价方案（如免费试用、折扣套餐），都必须显式调用 setOfferToken()。对于仅使用基础订阅的情况，可安全传入空字符串 ""：
private void makePurchase(ProductDetails productDetails) {
Print.e("makePurchase: " + productDetails.getName());
// ✅ 关键修复：必须设置 offerToken，即使是空字符串
String offerToken = ""; // 使用默认价格方案时设为空字符串
// 若需指定特定优惠（如 trial 或 discount），则从 productDetails.getSubscriptionOfferDetails() 中获取：
// if (!productDetails.getSubscriptionOfferDetails().isEmpty()) {
// offerToken = productDetails.getSubscriptionOfferDetails().get(0).getOfferToken();
// }
List<billingflowparams.productdetailsparams> productDetailsParamsList =
ImmutableList.of(
BillingFlowParams.ProductDetailsParams.newBuilder()
.setProductDetails(productDetails)
.setOfferToken(offerToken) // ← 必须存在且不可为 null
.build()
);
BillingFlowParams billingFlowParams = BillingFlowParams.newBuilder()
.setProductDetailsParamsList(productDetailsParamsList)
.build();
BillingResult billingResult = billingClient.launchBillingFlow(activity, billingFlowParams);
Print.e("launchBillingFlow result: " +
"code=" + billingResult.getResponseCode() + ", " +
"debug=" + billingResult.getDebugMessage());
}</billingflowparams.productdetailsparams>
⚠️ 注意事项：
- offerToken 不可为 null，但可以是 ""（空字符串）——这是 Google 官方认可的默认方案标识；
- 若应用支持多档订阅优惠（如 7 天试用、首月 5 折），应遍历 productDetails.getSubscriptionOfferDetails() 获取对应 offerToken，并根据业务逻辑选择；
- 确保 productDetails 已成功查询返回（即 queryProductDetailsAsync() 成功），且其 getProductType() 为 SUBS；
- launchBillingFlow() 必须在主线程调用，且 activity 需处于活跃状态（!activity.isFinishing() && !activity.isDestroyed()）；
- 测试时务必使用真实测试账号（非开发者账号）并开启 License Testing，沙盒环境对订阅流程更敏感。
? 总结：这不是 Bug，而是 Billing Library 5.0+ 对订阅模型的强制契约设计。setOfferToken() 不是“可选增强”，而是订阅购买的必要字段。忽略它不会报错，但会导致整个支付流程静默失效——这是文档表述模糊引发的典型集成陷阱。始终显式设置 offerToken，是保障订阅支付可靠启动的第一道防线。
