The Architecture of tdlib-android: Eliminating Raw JNI

The Problem with TDLib on Android

Compiling TDLib for Android is notoriously difficult. It requires dealing with NDK versions, CMake configurations, and endless C++ dependencies. Even after compiling, you're left with raw JNI functions that are error-prone and unidiomatic in Kotlin.

Why Raw JNI is a Bottleneck

When building Telegram clients, direct JNI calls mean manual memory management, pointer casting, and an explosion of boilerplate. A single null reference can crash the entire VM. The typical approach involves generating hundreds of external Kotlin functions and manually mapping C++ structs to Java classes.

The tdlib-android Solution

To fix this, I engineered io.github.tdlib-android:core. Instead of making every developer figure out CMake, I created an automated GitHub Actions pipeline that cross-compiles the official tdlib source against aarch64-linux-android, arm-linux-androideabi, x86_64-linux-android, and i686-linux-android.

Automated CI/CD Pipeline

The CI pipeline is triggered weekly. It pulls the latest TDLib version from the official repository, injects a custom CMake configuration that sets the ANDROID_NDK_HOME, and triggers Ninja builds. The resulting .so files are stripped of debug symbols (reducing binary size by 40%) and bundled into an AAR.

Idiomatic Kotlin Wrappers

But distributing the AAR isn't enough. I wrote a Python code-generator that parses the TDLib TL schema and emits idiomatic Kotlin data classes and suspend functions. Instead of:

long clientId = TdApi.createClient();
TdApi.send(clientId, new TdApi.GetMe());

You get:

val me = tdClient.getMe()

All JSON serialization is handled natively via Kotlinx.Serialization.

Conclusion

By solving this at the infrastructure level, developers can now just add implementation("io.github.tdlib-android:core:1.8.64") and start building. This drastically lowered the barrier to entry for building custom Telegram clients on Android.