期限をクリアする道は 2 つあります。どちらも有効ですが、このコードラボでは 2 つ目をおすすめします。

単一の商品しか販売しておらず、ペイウォール、実験、クロスプラットフォーム対応を追加する予定が今後もないなら、 手作業でのパッチでも問題ありません。ただ大半のアプリでは、1 つ目の道にかかる毎年のコストこそが、2 つ目を選ぶ理由になります。

参考までに、素の Billing Library が v8（2025 年 6 月 30 日リリース）で削除したものを挙げます。手作業でパッチを当てるなら、 これが作業リストです。RevenueCat へ移行するなら、逆にこのコードを削除することになります。

v9（2026 年 5 月 19 日）の変更は小さいものの、それでもコードに影響します。ブロックされた Play Store のエラーが ERROR から BILLING_UNAVAILABLE に変わり、外部支払いのフィールドが nullable になり、 ターゲット SDK が 35 に引き上げられました。（onProductDetailsResponse リスナーのシグネチャ変更と、新しい課金サブレスポンスコードは v8 の時点で入っています。）最小 SDK は v8.1 で API 23 (Android 6.0) に上がりました。

RevenueCat Android SDK は、Google Play Billing Library を同梱して管理します。現行の SDK は推移的依存として Billing Library 8.3.0 を同梱しているので、com.android.billingclient:billing を自分で追加する必要はなく、 BillingClient を呼び出すこともまったくありません。

これが毎年の期限にとって意味するのは次のことです。

• 今: RevenueCat SDK を一度だけ導入します（このコードラボの残りの内容）。
• 翌年、v9 や v10 が必須になったとき: RevenueCat SDK のバージョンを上げるだけです。BillingClient の書き直しも、削除された API 探しもありません。

さらに、本来なら自分で作ることになるものも手に入ります。単一の情報源となる customerInfo.entitlements、 サーバー側のレシート検証、Webhook、そして後から使える Paywalls、Experiments、Customer Center です。

アプリモジュールの Gradle ファイルに SDK を追加します（最新バージョンを使ってください）。

// app/build.gradle.kts
dependencies {
    implementation("com.revenuecat.purchases:purchases:10.10.0")
    // Optional: paywalls + Customer Center (requires minSdk 24)
    // implementation("com.revenuecat.purchases:purchases-ui:10.10.0")
}
// Remove your old: implementation("com.android.billingclient:billing:...")

この SDK は minSdk 23 (Android 6.0) が必要です。Application クラスで一度だけ構成します。

// MainApplication.kt
class MainApplication : Application() {
    override fun onCreate() {
        super.onCreate()

        Purchases.logLevel = LogLevel.DEBUG
        Purchases.configure(
            PurchasesConfiguration.Builder(this, "goog_YOUR_PUBLIC_SDK_KEY")
                // .purchasesAreCompletedBy(PurchasesAreCompletedBy.REVENUECAT) // default: full migration
                .build()
        )
    }
}

RevenueCat は、ハードコードした SKU と独自の「プレミアムかどうか」の判定を、小さくて長く使えるモデルに置き換えます。次の要素をダッシュボードで構成します。

ダッシュボードでは、既存の Google Play 商品をインポートし、エンタイトルメント（たとえば pro）を作成して、各プロダクトをそれに Attach します。

queryProductDetailsAsync / launchBillingFlow / 承認のコードを削除し、 2 つの呼び出しに置き換えます。まず、何を販売するかを取得します。

// Coroutines: fetch the current offering and its packages
val offerings = Purchases.sharedInstance.awaitOfferings()
val packages = offerings.current?.availablePackages.orEmpty()
// Show `packages` in your UI (each pkg.product carries the localized price)

次に、ユーザーが選んだパッケージから購入します。

try {
    val result = Purchases.sharedInstance.awaitPurchase(
        PurchaseParams.Builder(activity, selectedPackage).build()
    )
    val customerInfo = result.customerInfo
    if (customerInfo.entitlements["pro"]?.isActive == true) {
        // Unlock pro. RevenueCat already acknowledged the purchase with Google.
    }
} catch (e: PurchasesTransactionException) {
    if (!e.userCancelled) {
        // Show a real error; userCancelled just means the user backed out.
    }
}

コルーチンを使っていない場合は、コールバック形式の同等版 (getOfferingsWith、purchaseWith) もあります。

RevenueCat の SDK は初めてですか? Android コードラボと 商品と価格の取得ガイドで、さらに詳しく解説しています。

ここがもっとも重要な部分です。現在の有料ユーザーがアクセスを失ってはいけません。作業は 2 つあり、両方とも行うのが望ましいです。

1. 新しい購入: 自動で追跡する

Google Play アカウントをすでに接続したうえで（Google Play 連携コードラボを参照）、 Google Play のサーバー通知を設定し、サーバー間通知から新しい購入を追跡をオンにします。すると RevenueCat は、 SDK をまだ含まないアプリバージョンからのものも含め、すべての新しい購入を記録します。

2. 既存の購入: 一度だけ同期する

以前の BillingClient コードですでにサブスクライブしたユーザーには、RevenueCat 対応ビルドの初回起動時に syncPurchases() を一度だけ呼び出します。これは OS のサインインを求めることなく、既存の Google Play 購入を RevenueCat に送ります。ステップ 6 のプロダクトとエンタイトルメントの紐付けと組み合わせれば、その人の pro アクセスは自動的に復元されます。

// Run ONCE per subscriber, the first time they open the RevenueCat build.
if (!prefs.getBoolean("rc_migrated", false)) {
    Purchases.sharedInstance.syncPurchasesWith(
        onError = { /* retry later */ },
        onSuccess = { _ -> prefs.edit().putBoolean("rc_migrated", true).apply() }
    )
}

リリース前に、課金されることなく実機で移行を検証します。

1. Play Console で Setup > License testing にテスターを追加し、ビルドを Internal または Closed testing トラックに公開します。
2. 既存のサブスクリプションを持つテスターとして、新しい RevenueCat ビルドをインストールし、一度きりの syncPurchases が実行され、pro エンタイトルメントがアクティブになることを確認します。
3. 新規のテスターとして、新しいフローで購入を完了し、エンタイトルメントがアンロックされ、トランザクションが RevenueCat に表示されることを確認します。
4. RevenueCat ダッシュボードで該当の顧客を確認し、購入とエンタイトルメントが記録されているかを確かめます。

段階的なロールアウトがよい? オブザーバーモードを使う

課金コードを 1 回のリリースで削除する準備ができていない場合は、RevenueCat を PurchasesAreCompletedBy.MY_APP で構成します。すると、既存のコードが購入を完了（承認）しつつ、 RevenueCat が購入とエンタイトルメントを記録します。以前の購入コードを削除したら、デフォルトの PurchasesAreCompletedBy.REVENUECAT に切り替えてください。

Android アプリを素の Billing Library から RevenueCat へ移行しました。

• BillingClient（と v8 で削除された API に伴うすべての手直し）を getOfferings + purchase に置き換えました。
• アクセスの判定を、手作りの SKU ロジックではなく、単一の pro エンタイトルメントとしてモデル化しました。
• 一度きりの syncPurchases とプロダクトとエンタイトルメントの紐付けで既存サブスクライバーを移行し、Historical Import で履歴を埋め戻しました。

得られるもの: 2026 年 8 月 31 日の期限をクリアし、v9、v10 とそれ以降が必須になっても、RevenueCat SDK を上げるだけで済みます。 毎年の Billing Library 移行はもう不要です。

次に進む

• Android アプリ内課金とペイウォール: RevenueCat Android 連携の全体像。
• アプリ収益を伸ばすと商品と価格の取得: 課金が片付いた今、何をするか。
• RevenueCat: 既存サブスクリプションの移行とGoogle: Billing Library 8 への移行。