Rc Configuring The Sdk

RevenueCat/ai-toolkit/revenuecat-play-billing/skills/rc-configuring-the-sdk

作者 RevenueCatccfc038185ec457b2ac9077f3bbf1ba947a44dbbApache-2.0; see LICENSE收錄於 2026年10月9日更新於 2026年10月9日

Use this skill when adding and configuring the RevenueCat Android SDK (purchases-kt/purchases) in an app. Covers the Gradle dependency, Purchases.configure with PurchasesConfiguration, initial app user id strategy, and log level.

AI 產生的概覽

指導在應用程式中加入與設定 RevenueCat Android SDK(purchases-kt),涵蓋 Gradle 相依性到 configure 呼叫。

功能
依探索、規劃與執行三個階段,說明如何將 RevenueCat Android SDK 接入應用程式。內容包括 Gradle 相依性、使用 PurchasesConfiguration 的 Purchases.configure 呼叫、應用程式使用者 ID 策略、記錄層級,以及用來確認設定的最小 offerings 取得。也列出 SDK 自動處理的事項與常見問題。
適用情境
適用於在 Android 應用程式中整合或設定 RevenueCat purchases-kt,或以其取代手動 BillingClient 設定。也適合排查與 configure 相關的問題,例如單例執行個體缺失或 offerings 為 null。
執行需求
僅為說明文件,不含指令碼。需要具備 Gradle 的 Android 專案、com.revenuecat.purchases:purchases 相依性、RevenueCat 公開 Android SDK 金鑰,以及用於 offerings 檢查的網路存取。

Configuring the RevenueCat Android SDK

Use this skill to add and configure RevenueCat (purchases-kt) in an Android app. A single Purchases.configure call replaces BillingClient setup, connection lifecycle management, reconnection handling, and launch-time purchase queries.

Work through the phases in order. The full chapter on revenuecat.com has the complete reference text.

Phase 1: Discovery

Find out whether RevenueCat is already wired up and where billing code currently lives.

  1. Search for an existing configure call and prior SDK version.

    bash
    rg -n "Purchases\.configure|PurchasesConfiguration" --type kotlin --type javarg -n "com\.revenuecat\.purchases" -g '*.gradle*' -g '*.toml'
  2. Search for the existing billing surface you may be replacing.

    bash
    rg -n "BillingClient|PurchasesUpdatedListener|startConnection" --type kotlin --type java
  3. Record answers before moving on.

QuestionWhere to look
Is Purchases.configure already called?App startup, Application.onCreate, main Activity.onCreate
Which module owns billing today?app/build.gradle(.kts), any :billing module
Is there an auth system with a stable user id?Login flow, session store
Debug vs release build detection available?BuildConfig.DEBUG

If Purchases.configure already runs, stop and confirm with the user before changing it. Configuration runs once per process.

Phase 2: Plan

Decide three things before writing code.

2.1 Where to call configure

LocationWhen to choose
Application.onCreateDefault. Ensures the SDK is ready before any Activity or background work touches purchases.
First Activity.onCreateOnly if the app has no custom Application class and you are not willing to add one.

Call configure exactly once per process. Calling it from an Activity risks re-running it on configuration changes if you are not careful; the Application path avoids that.

2.2 App user id strategy

StrategyPass to appUserIDUse when
AnonymousnullUsers can purchase before signing in, or you have no auth. Later call Purchases.sharedInstance.logIn(id) to merge history.
Known userYour stable backend id (for example "user_12345")Users are always authenticated before purchase.

Do not pass device ids, email addresses, or values that can change. If you do not have the id at startup, configure anonymously and call logIn after authentication.

2.3 Log level

BuildLog level
DebugLogLevel.DEBUG or VERBOSE while integrating
ReleaseLogLevel.INFO (default) or WARN

Switch on BuildConfig.DEBUG so production builds stay quiet.

Phase 3: Execute

3.1 Add the Gradle dependency

In the app module build.gradle.kts:

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

Replace <latest> with the current published version. If the project uses a Groovy build.gradle, use implementation 'com.revenuecat.purchases:purchases:<latest>'. Sync Gradle after the change.

3.2 Call configure at startup

In your Application subclass:

kotlin
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()        )    }}

Register the class in AndroidManifest.xml with android:name=".App" on <application>. Keep the public Android SDK key out of source; inject it through BuildConfig or a secret manager.

3.3 Confirm the wiring with a minimal offerings fetch

From any coroutine scope after configure has run:

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

A non-null offerings.current identifier means the API key, package name, and network path are working. If you see null, check the dashboard offering setup and the package name match before touching code.

What the SDK handles for you

Once configured, you do not need to:

  • Create or close a BillingClient
  • Call startConnection or endConnection
  • Check isReady or write reconnection logic for SERVICE_DISCONNECTED
  • Call queryPurchasesAsync at launch; the SDK posts unfinished transactions automatically

Common pitfalls

SymptomLikely cause
IllegalStateException: There is no singleton instanceCode touched Purchases.sharedInstance before configure ran. Move configure to Application.onCreate.
Offerings always nullPackage name mismatch between Play Console and dashboard, or offering not marked current.
Duplicate anonymous usersconfigure called more than once per process, or an unstable id passed as appUserID.
Verbose logs in productionLog level not gated on BuildConfig.DEBUG.

References

來源與署名

來源:RevenueCat/ai-toolkit位於revenuecat-play-billing/skills/rc-configuring-the-sdk提交ccfc038

授權條款: Apache-2.0; see LICENSE

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架