▸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
Google's recent policy auto-declares the AD_ID permission in your merged manifest if any dependency uses the Ads SDK or AdvertisingIdClient. Many teams discover the permission only when Google Play flags it — usually from a transitive dependency they didn't realize was pulling Ads SDK. Respectlytics's Android SDK has zero Google Play Services dependencies, so it cannot contribute to that merge.
The Google Play Data Safety form's "Advertising or marketing IDs" category is one of the most-flagged categories in audits. Apps that declare it correctly because of an embedded Ads SDK get fine; apps that declare "No" without realizing a transitive dependency does collect AAID get rejected. Respectlytics's no-Ads-SDK posture means you can answer "No" honestly for our SDK's contribution.
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
| AAID handling | Firebase Analytics | Mixpanel | AppsFlyer | Respectlytics |
|---|---|---|---|---|
| Reads AAID via AdvertisingIdClient | Yes | Yes (optional) | Yes (mandatory) | No |
| Adds AD_ID permission to manifest | Yes (auto-merged) | Conditional | Yes | No |
| Stores AAID in events | Yes | Optional | Yes | Never |
| Effect on Google Play Data Safety | Triggers ad-ID category | Triggers ad-ID category | Triggers ad-ID category | No ad-ID category from us |
| Cross-app tracking surface | AAID-linked | AAID-linked | AAID-linked | None |
❓Frequently asked questions
How do we tell if AAID is being collected by another SDK in our app?
Check the merged manifest at app/build/intermediates/merged_manifests/release/AndroidManifest.xml — if it contains <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>, some dependency is contributing it. Often it's Firebase Analytics, AdMob, or an attribution SDK pulled by your build. Removing those dependencies removes the permission.
Will Google Play reject my app for not declaring AD_ID?
No. Apps that don't use AAID don't need to declare the permission — and Google's Data Safety form lets you tick "No, this app does not collect advertising ID". Confirm with your legal team based on what other SDKs in your app do.
Does Respectlytics use any device-level identifier on Android?
Only the rotating session_id (RAM-only, regenerated every 2 hours and on app restart). No Settings.Secure.ANDROID_ID, no Build.SERIAL, no MAC address, no IMEI.
What happens on devices without Google Play Services?
Same as on devices with Google Play Services: no AAID, just the session_id. Respectlytics has no Google Play Services dependency at all, so the SDK's behaviour is identical on non-GMS devices (Huawei AppGallery, F-Droid, etc.).