Fire the call inside the share-sheet completion callback when the user has actually completed the share (not when they open the sheet — abandonment is common). Encode the chosen channel into the event name.
▸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.
▸Track the event in Kotlin (Android)
import android.content.Intent
import androidx.activity.result.contract.ActivityResultContracts
import com.respectlytics.android.Respectlytics
fun shareContent(activity: ComponentActivity, text: String) {
val intent = Intent.createChooser(
Intent(Intent.ACTION_SEND).apply {
type = "text/plain"
putExtra(Intent.EXTRA_TEXT, text)
},
"Share via",
)
val launcher = activity.registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
if (result.resultCode == android.app.Activity.RESULT_OK) {
// Android's chooser doesn't reliably tell you which app — fire generic.
Respectlytics.track("share_completed")
} else {
Respectlytics.track("share_cancelled")
}
}
launcher.launch(intent)
}Android's chooser intent doesn't reliably return the chosen activity until API 33+. For finer-grained channel attribution, call individual share intents per-channel and fire distinct event names there.
✦Privacy & implementation notes
Putting the channel as a parameter ({ channel: 'twitter' }) is the natural first instinct and is exactly what Respectlytics's API rejects. Encode it as the event name — share_twitter — and you get the same downstream queryability without storing parameters.
Fire on share completion, not on share-sheet presentation. Share-sheet presentation is fairly common (the user is just exploring); actual completion is much rarer and is the meaningful signal. The two rates differ by 5–10× in most apps.
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
| Share event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Share channel as parameter | Recommended | Recommended | Use distinct event_name |
| Shared content ID | Recommended | Recommended | Out of scope (use content backend) |
| Recipient data (when accessible) | Possible | Possible | Forbidden (PII) |
| Per-user share count | Yes | Yes | Out of scope |
| Share rate by content / channel | Per-user | Per-user | Use distinct event_names + content backend |
❓Frequently asked questions
How do we know which channels are most popular?
Distinct event names per channel: share_imessage, share_email, share_twitter, share_copy_link. Aggregation gives per-channel rate. iOS's UIActivityViewController and Android's Intent chooser deliver the selected channel in the completion callback — encode it into the event name.
What about shared content metadata?
Stays in your content backend. The CMS or content database knows what was shared. Respectlytics tells you that a share happened in this session — the join to specific content is a backend concern.
Can we measure share-induced installs?
Server-side via deferred deep links and install attribution. App Store Connect / Play Console deliver the attribution; your backend correlates the shared link's tracking parameter with the resulting install. Respectlytics doesn't ingest install attribution — it's not the right system for that.
What if the share sheet completes but the user cancels?
iOS's UIActivityViewController and Android's Intent chooser both call back with a cancellation flag. Don't fire share_* on cancel — fire share_cancelled (a single event regardless of channel) if you want to track abandonment.