▸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
AGPL-3.0 is a common license for SaaS-as-source projects (Plausible, Matomo, GitLab Community Edition). The license design is to prevent vendors from forking the project, modifying it privately, and offering their fork as a competing closed-source SaaS — but it does not impede internal self-hosting at all. For most enterprise self-hosters, the license is a non-issue.
Self-hosted Respectlytics is operated by the same management commands and Django infrastructure as our cloud — the deployment difference is purely the database hostname and the network egress profile. If you can run a Django + Postgres app on your infrastructure, you can run Respectlytics.
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
| Self-hosting | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Self-hostable | No | No | No (cloud-only) | Yes (AGPL-3.0 server) |
| SDK license | Apache 2.0 | Apache 2.0 | MIT | MIT |
| Server source available | No | No | No | Yes (public repo) |
| Operator-managed database | No | No | No | Yes (you choose) |
| Air-gapped deployment possible | No | No | No | Yes |
❓Frequently asked questions
What infrastructure do we need to self-host?
A Linux box (or container) running Python 3.12, Postgres 14+ (managed or self-managed), and a reverse proxy (nginx / Caddy / similar). The default configuration scales to ~10 million events/day on a 4-vCPU / 8 GB box; larger deployments scale horizontally. Hardware requirements are documented in the public README.
What's the AGPL-3.0 obligation?
If you modify the server source AND offer the modified server as a service to third parties (over a network), you must publish your modifications under the same license. Internal self-hosting for your own apps does NOT trigger publication obligations — it's only when you offer the server to others over a network. Consult your legal team for specific applicability; the FSF's AGPL FAQ is the canonical reference.
Are SDK changes also covered by AGPL?
No. The SDKs (Swift, Kotlin, RN, Flutter) are MIT-licensed — fork and modify freely with no copyleft obligation. Only the SERVER is AGPL.
Do self-hosted instances get our updates automatically?
No — you upgrade by pulling the latest source and running migrations. We publish release notes for each version. There's no auto-update; self-hosting means you control the deployment cadence.