▸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
iOS keychain dumps and Android file-system dumps from rooted/jailbroken devices routinely surface analytics artifacts: distinct_ids, device_ids, queued events sometimes containing PII. The typical retention is months to years because most analytics SDKs don't expose a clear-data API and users don't think to clear analytics state. Respectlytics's RAM-only approach moves the dump-recovery surface to zero.
The 30-second flush cadence + RAM-only queue makes Respectlytics well-suited to apps with strict device-data policies: telehealth, fintech, and government apps where forensic recoverability of analytics data is itself a documented risk. The trade-off — losing events on force-quit — is an acceptable cost in those contexts.
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
| Device storage for analytics | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Persistent event queue on disk | Yes (sqlite) | Yes (sqlite) | Yes (sqlite) | No (RAM only) |
| User-defaults / preferences usage | Yes (instance ID) | Yes (distinct_id) | Yes (device ID) | No |
| Survives force-quit before flush | Yes | Yes | Yes | No (events lost — by design) |
| Disk space used | 0.5–5 MB typical | 1–10 MB | 1–5 MB | 0 bytes |
| Forensic data on device | Persistent identifiers, queues | Same | Same | None |
❓Frequently asked questions
What happens if the app is force-quit before events are flushed?
Those events are lost — and we treat that as the correct behaviour, not a bug. A handful of dropped events is the price of a privacy-by-architecture posture: nothing on disk means there's nothing on the device for an attacker, a forensic tool, or an unintended share to recover. Empirically, force-quit between visible activity and the SDK's flush interval (default 30 seconds) is a small fraction of all events.
Doesn't this reduce data quality?
Marginally. The trade-off is real — most analytics SDKs would rather lose 0% of events than 1%. We accept the 1% loss in exchange for eliminating an entire category of forensic and supply-chain risk. For aggregate analytics — funnel rates, feature adoption, release deltas — 1% loss is not material. For individual user reconstruction, it would be — but that use case doesn't apply to Respectlytics anyway.
What about the SDK's own configuration / app key?
The app key is in your bundled app code (it's a build-time constant, not a secret). The SDK doesn't write it back to disk. The session_id lives in process memory only and rotates.
Does this affect debug builds or local testing?
No — the SDK behaves identically in debug. If you want to introspect the queue during development, the SDK exposes a debug API that prints queued events to the console (still no file writes).