Track from Android

This tutorial gets the Binoban Native SDK sending its first identify and track events from an Android app. The SDK is one Kotlin Multiplatform core; this page covers the Android output of that core.

Before you begin

You need:

• An Android app you can build, targeting minSdk 21+.
• Your Binoban source credentials — apiKey and sourceIdentifier — and your apiHost, all from your Binoban workspace. (New to credentials? See the Quick Start.)

apiHost is required

Unlike the Web SDK, the Native SDK needs an explicit apiHost — there is no default on Android. If it is blank, the SDK initializes in a disabled (no-op) state and sends nothing. For on-prem or air-gapped deployments, use your own deployment's host.

Step 1 — Add the dependency

The SDK is published to Maven Central. Make sure mavenCentral() is in your repositories, then add the dependency to your module's build.gradle.kts:

dependencies {
    implementation("io.binoban.sdk:sdk-android:1.1.0")
}

Use the current version

1.0.0 is shown for concreteness. Check the SDK compatibility matrix for the current version and platform status.

Step 2 — Initialize the SDK

Create the client once, in your Application.onCreate(), and keep a reference to it. The Android build needs the application context, your credentials, and an explicit apiHost.

import android.app.Application
import io.binoban.sdk.core.Binoban

class MainApplication : Application() {
    companion object {
        lateinit var binoban: Binoban
    }

    override fun onCreate() {
        super.onCreate()
        val app = this
        binoban = Binoban("YOUR_API_KEY", "YOUR_SOURCE_IDENTIFIER") {
            application = app
            apiHost = "YOUR_API_HOST"   // required — no default on Android
        }
    }
}

The SDK generates and persists an anonymous ID at this point, so it can attribute activity even before a user signs in.

The companion object is what makes the client reachable from the rest of your app — anywhere else, you call it as MainApplication.binoban. The remaining steps use that form. (Injecting the client with Hilt or Koin works just as well; the companion keeps this tutorial to one file.)

Step 3 — Identify the current user

When the user signs in, call identify with your own user ID and any traits:

MainApplication.binoban.identify(
    userId = "user_123",
    traits = buildJsonObject {
        put("name", "Jane Doe")
        put("email", "jane@example.com")
    },
)

Step 4 — Track an action

track records something the user did — its first argument is the event name, its second a properties object:

MainApplication.binoban.track("signed_up", mapOf("plan" to "Enterprise"))

Step 5 — Flush and verify

The SDK batches events and sends them automatically (every flushAt events or flushInterval seconds). To send immediately during testing, flush by hand:

MainApplication.binoban.flush()

Then confirm delivery: watch your app's network traffic for a POST to …/api/tracker/sdk/android returning 200. Unlike the Tracking REST API, the SDK-facing endpoint has no {sourceIdentifier} path segment or /track suffix — every platform's SDK posts its batch to one fixed per-platform path, and the apiKey on the Bearer header identifies the source. A 401 means the apiKey is wrong; a connection failure points at the apiHost. As with the Web SDK, a 200 means Binoban accepted the event — it then resolves into your source's profiles in the workspace.

What you've done

You added the SDK, initialized it with the required apiHost, identified a user, tracked an action, and verified delivery — the full Android tracking loop.

Next steps

• See a working example → binoban-example-android, a minimal Compose app wiring up everything above plus opt-in push. See Example Apps for all three platforms.
• Full method surface and configuration → the Android SDK reference — every method signature, the configuration options table, identity reads, runtime controls, and FCM push-token registration.
• iOS instead? See the iOS tutorial.
• React Native? The React Native SDK wraps these same native outputs (screen/group/alias are internal on every platform — not an RN-specific gap).
• Model identity well across platforms → Identity strategy, including deviceId and multi-device behavior.
• Before production → the Go-live checklist.