▸Install the Kotlin (Android) SDK
// build.gradle.kts (app module)
dependencies {
implementation("com.respectlytics:respectlytics-kotlin:3.0.0")
}Pure Kotlin coroutines implementation. No Java dependencies, no Google Play Services dependencies. ~300KB DEX overhead — compare to roughly 3.8MB for Firebase Analytics (a measurable cold-start improvement on lower-end devices).
▸Initialize Respectlytics in Kotlin (Android)
import com.respectlytics.android.Respectlytics
class MyApplication : Application() {
override fun onCreate() {
super.onCreate()
Respectlytics.configure(this, appKey = "<YOUR_APP_KEY>")
}
}Initialize once in Application.onCreate. No additional permissions in the manifest — INTERNET is sufficient. The SDK does not request AD_ID, does not query AdvertisingIdClient, and does not declare ACCESS_NETWORK_STATE.
✦Privacy & implementation notes
Probabilistic install-attribution SDKs (AppsFlyer, Branch, Adjust) build fingerprints from model + OS + screen + locale + IP and match them across the install boundary to attribute the install to a specific ad click. Apple's SKAdNetwork and Google's Privacy Sandbox are the non-fingerprinting alternatives. Respectlytics is event analytics, not install attribution — but if you remove the install-attribution SDK from your app, the fingerprint surface goes with it.
Audit indicator: search your build for Locale.current, UIDevice.current, Build.MODEL, screen.width, Intl.DateTimeFormat().resolvedOptions().timeZone — these are the canonical fingerprint signals that SDKs reach for. If they appear in your shipped code only as part of your own UI logic (not as analytics-emission), you're clean.
Many teams discover the com.google.android.gms.permission.AD_ID permission in their merged manifest only after Google Play flags them — usually because a transitive dependency dragged it in. Respectlytics's Kotlin SDK has no Google Play Services dependency at all, so it cannot contribute to that merge.
The SDK is implemented as pure Kotlin coroutines with no Java sources, no RxJava, and no platform channels. Events are queued in a Channel<Event> buffered to a small ring (RAM-only), drained by a coroutine that flushes every 30 seconds or on backgrounding. There is no SharedPreferences usage.
⇋How this compares to other analytics SDKs
| Fingerprint signals | Firebase Analytics | AppsFlyer | Branch | Respectlytics |
|---|---|---|---|---|
| Model + OS version | Yes | Yes | Yes | No |
| Screen size + density | Yes | Yes | Yes | No |
| Locale + timezone | Yes | Yes | Yes | No |
| Installed font list | No | Sometimes | Sometimes | No |
| IP + User-Agent combination | Yes | Yes | Yes | IP transient, UA standard |
| Probabilistic install attribution | No | Yes | Yes | No |
❓Frequently asked questions
Does the SDK report ANY device characteristics?
Two: the platform field (iOS / Android / RN / Flutter — already in the 5-field schema) and the inferred country code from IP lookup. That's it. Model, OS version, screen size, locale, timezone are not collected.
What about User-Agent — that has model + OS in it on Android.
The HTTP request to our API includes a standard User-Agent that identifies the SDK and platform but does NOT include device model, OS build number, or other fingerprinting signals. We use a fixed UA string per SDK version + platform combination.
How do we still see crash data by device model, then?
From your crash reporter (Sentry, Crashlytics, Bugsnag) — those tools legitimately need device model for crash dedup. Respectlytics is event analytics, not crash analytics; the two have different data needs and should be wired separately.
What about A/B-test variant assignment using fingerprint stability?
Don't. Variant assignment via fingerprinting is a re-identification anti-pattern. Use a randomised assignment within your client, encode the variant in the event_name (paywall_purchase_a, paywall_purchase_b), and compute conversion rates from session-grouped event counts. No fingerprint needed.