rc-configuring-the-sdk

RevenueCat Android SDK の設定

このスキルを使って、Android アプリに RevenueCat（purchases-kt）を追加して設定します。Purchases.configure を一度呼び出すだけで、BillingClient のセットアップ、接続ライフサイクルの管理、再接続処理、起動時の購入クエリを置き換えられます。

各フェーズを順番に進めてください。revenuecat.com の完全版チャプターに、リファレンス全文が記載されています。

フェーズ 1：調査

RevenueCat がすでに組み込まれているか、現在どこに課金コードがあるかを確認します。

1. 既存の configure 呼び出しと以前の SDK バージョンを検索します。

   rg -n "Purchases\.configure|PurchasesConfiguration" --type kotlin --type java
   rg -n "com\.revenuecat\.purchases" -g '*.gradle*' -g '*.toml'
   

2. 置き換える可能性のある既存の課金処理を検索します。

   rg -n "BillingClient|PurchasesUpdatedListener|startConnection" --type kotlin --type java
   

3. 次に進む前に、回答を記録します。

質問	確認する場所
Purchases.configure はすでに呼び出されていますか？	アプリの起動処理、Application.onCreate、メインの Activity.onCreate
現在、どのモジュールが課金処理を担当していますか？	app/build.gradle(.kts)、:billing モジュール
安定したユーザー ID を持つ認証システムはありますか？	ログインフロー、セッションストア
デバッグビルドとリリースビルドを判別できますか？	BuildConfig.DEBUG

Purchases.configure がすでに実行されている場合は、変更する前に作業を止め、ユーザーに確認してください。設定はプロセスごとに一度実行されます。

フェーズ 2：計画

コードを書く前に、次の 3 点を決めます。

2.1 configure を呼び出す場所

場所	選択する場合
Application.onCreate	デフォルトです。Activity やバックグラウンド処理が購入処理に触れる前に SDK を利用可能にします。
最初の Activity.onCreate	アプリにカスタムの Application クラスがなく、その追加も避けたい場合に限ります。

プロセスごとに configure を一度だけ呼び出します。注意しないと、Activity から呼び出した場合に構成変更時に再実行されるおそれがありますが、Application を使えば回避できます。

2.2 アプリユーザー ID の方針

方針	appUserID に渡す値	使用する場合
匿名	null	ユーザーがサインイン前に購入できる場合、または認証がない場合。後から Purchases.sharedInstance.logIn(id) を呼び出して購入履歴を統合します。
既知のユーザー	安定したバックエンド ID（例："user_12345"）	購入前に必ずユーザー認証が行われる場合。

デバイス ID、メールアドレス、または変更される可能性がある値は渡さないでください。起動時に ID がない場合は、匿名で設定し、認証後に logIn を呼び出します。

2.3 ログレベル

ビルド	ログレベル
デバッグ	組み込み中は LogLevel.DEBUG または VERBOSE
リリース	LogLevel.INFO（デフォルト）または WARN

BuildConfig.DEBUG による切り替えを行い、本番ビルドではログを抑制します。

フェーズ 3：実行

3.1 Gradle の依存関係を追加する

アプリモジュールの build.gradle.kts に追加します。

dependencies {
    implementation("com.revenuecat.purchases:purchases:<latest>")
}

<latest> を現在公開されているバージョンに置き換えます。プロジェクトで Groovy の build.gradle を使っている場合は、implementation 'com.revenuecat.purchases:purchases:<latest>' を使用します。変更後に Gradle を同期します。

3.2 起動時に configure を呼び出す

Application のサブクラスに記述します。

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Purchases.logLevel =
            if (BuildConfig.DEBUG) LogLevel.DEBUG else LogLevel.INFO
        Purchases.configure(
            PurchasesConfiguration.Builder(this, BuildConfig.RC_API_KEY)
                .appUserID(null) // or your stable user id
                .build()
        )
    }
}

AndroidManifest.xml の <application> に android:name=".App" を指定して、このクラスを登録します。公開 Android SDK キーをソースコードに含めないでください。BuildConfig またはシークレットマネージャーを通じて注入します。

3.3 最小限の offerings 取得で設定を確認する

configure の実行後、任意のコルーチンスコープから次を実行します。

lifecycleScope.launch {
    val offerings = Purchases.sharedInstance.awaitOfferings()
    Log.d("RC", "current=${offerings.current?.identifier}")
}

offerings.current の識別子が null 以外であれば、API キー、パッケージ名、ネットワーク経路が機能しています。null が返る場合は、コードを変更する前にダッシュボードの offering 設定とパッケージ名が一致しているか確認してください。

SDK が自動的に処理する内容

設定後は、次の処理は不要です。

• BillingClient の作成や終了
• startConnection または endConnection の呼び出し
• isReady の確認や、SERVICE_DISCONNECTED に対する再接続処理の実装
• 起動時の queryPurchasesAsync の呼び出し。SDK が未完了のトランザクションを自動的に送信します

よくある問題

症状	考えられる原因
IllegalStateException: There is no singleton instance	configure の実行前に、コードが Purchases.sharedInstance にアクセスしています。configure を Application.onCreate に移動してください。
Offerings が常に null	Play Console とダッシュボードの間でパッケージ名が一致していないか、Offering が current としてマークされていません。
匿名ユーザーが重複する	1 つのプロセス内で configure が複数回呼び出されているか、不安定な ID が appUserID として渡されています。
本番環境で詳細なログが出力される	ログレベルが BuildConfig.DEBUG によって制御されていません。

参考資料

• 章の全文