The Zendesk Android SDK
The Android half of the story. Same concepts as iOS, different build system, and one platform quirk around push that catches teams out repeatedly.
What it does
The Android SDK embeds Zendesk support surfaces in your own app: a persistent messaging conversation, ticket creation and history on the older support line, help centre content from Guide, and push notifications when an agent replies.
As on iOS, the packaging has been reorganised over the years and old artifact names are still all over the internet. Take current Maven coordinates, the minimum SDK level and the support status from the current SDK reference rather than from a three year old tutorial. The architecture below has been stable across generations. The exact class names have not.
If you have not read the iOS side, the decision framework there applies equally here. Android adds two wrinkles the iOS build doesn't have: a far wider spread of devices and OS versions to support, and manufacturer software that interferes with background delivery. Both of them show up in the push section below, and both are the reason an Android integration takes longer to call finished than the iOS one did.
Zendesk Android SDK Gradle setup
Zendesk publishes to its own Maven repository, so the first job is telling Gradle where to look. In modern projects that lives in settings.gradle.kts rather than the app build file:
// settings.gradle.kts
dependencyResolutionManagement {
repositories {
google()
mavenCentral()
maven { url = uri("https://zendesk.jfrog.io/artifactory/repo") }
}
}Then the dependency itself:
// app/build.gradle.kts
dependencies {
implementation("zendesk.messaging:messaging-android:<current-version>")
}Confirm both the repository URL and the artifact coordinate against the current SDK reference, since these have moved between SDK generations. Two things to expect: the SDK will raise your minSdk if you are supporting very old devices, and it pulls in a chunk of AndroidX, which is fine unless your app is unusually lean about method count.
Initialising, in Kotlin
Initialise once, early, typically in your Application class. The messaging SDK takes a channel key generated in Admin Center. The older support SDK wanted a subdomain URL, app ID and client ID, which is how you tell which generation a sample belongs to.
class MyApp : Application() {
override fun onCreate() {
super.onCreate()
Zendesk.initialize(
context = this,
channelKey = BuildConfig.ZENDESK_CHANNEL_KEY,
successCallback = { Log.d("Zendesk", "initialised") },
failureCallback = { Log.e("Zendesk", "init failed", it) },
messagingFactory = DefaultMessagingFactory()
)
}
}Opening the conversation is then one call from wherever your help button lives:
helpButton.setOnClickListener {
Zendesk.instance.messaging.showMessaging(this)
}Check the current SDK reference for exact parameter names and the messaging accessor in your version. Keep the channel key out of source control and inject it through a build config field or a properties file, the same way you handle any other key.
Identity
Same model as every other Zendesk SDK. Your backend signs a JWT with a shared secret, your app fetches it, the SDK logs in with it.
Zendesk.instance.loginUser(
jwt = tokenFromYourBackend,
successCallback = { user -> Log.d("Zendesk", "user ${user.id}") },
failureCallback = { error -> Log.e("Zendesk", "login failed", error) }
)The secret lives on your server. Never in the APK. Android binaries are trivially decompiled, and a leaked signing secret means anybody can impersonate any customer in your account. Call the logout equivalent when the user signs out of your app, and clear the local conversation state with it, because shared devices are far more common on Android than product teams assume.
Push, and the Android-specific trap
Push runs through Firebase Cloud Messaging. You upload FCM credentials to Zendesk, pass the device token to the SDK once the user is known, and route incoming messages from your FirebaseMessagingService so the SDK can claim the ones that belong to it:
override fun onMessageReceived(message: RemoteMessage) {
if (Zendesk.instance.messaging.handleNotification(this, message.data)) return
handleYourOwnNotification(message)
}Here's the trap. Several Android manufacturers apply aggressive battery optimisation that delays or drops background push for apps the user has not opened recently. Your notification code is correct and the message still arrives forty minutes late on that one handset. If your support experience depends on timely replies, test on real devices from the manufacturers your users actually own, not just on an emulator, and consider prompting users to exempt your app from battery optimisation.
Also remember Android 13 and later require runtime notification permission. Ask for it at a moment that makes sense, ideally when someone opens support for the first time, not on first launch when they have no reason to say yes.
Is it worth it
Use the SDK when users are signed in, when conversations are ongoing rather than one-off, and when device context genuinely changes the answer. Attach app version, device model, OS version and account tier as fields on the conversation and you remove an entire round trip from a large share of tickets.
Skip it when your app is a thin front end for a website, when mobile support volume is small, or when your release cadence means a bug in an embedded surface sits in production for a month. A link to a fast, well built help centre isn't a failure. A slow native screen nobody maintains is worse.
Frequently asked questions
Does the SDK work with Kotlin?
Yes. The Zendesk Kotlin SDK usage is the same library called from Kotlin, and a Zendesk Android integration needs the Gradle dependency, an init call and push set up.
Which artifact do I add for the Zendesk Android SDK?
It depends on which SDK line you're on, and the coordinates have changed between generations. Take the current group, artifact and version from the current SDK reference rather than an old tutorial.
Does the Zendesk Android SDK support Jetpack Compose?
The SDK surfaces are activities and views, which you launch from Compose without wrapping. That works, though it will not match a Compose design system visually.
Why are push notifications delayed on some Android phones?
Manufacturer battery optimisation, not the SDK. Some vendors restrict background delivery for apps used infrequently. Test on the handsets your users actually carry.
How much does the SDK add to my APK size?
Enough to notice, though R8 shrinking helps. Measure it in your own build before and after, since it depends on what AndroidX you already ship.
Can I customise the look of the SDK screens?
Theming and colour customisation is supported to a degree, mostly through Admin Center configuration rather than in code. Do not expect full control over the layout.
Two channels, one problem, two tickets
App messaging plus email means the same customer question arrives twice. Ticket Merger finds and merges the pair automatically.
Start free trial14-day free trial. No credit card required.