Telegram Database Library as signed AARs, built and verified entirely in CI. Drop a Gradle dependency in and ship — no local compilation, no 16KB-page surprises.
// two lines and you have Telegram's core dependencies { implementation("io.github.tdlib-android:core:0.1.1") implementation("io.github.tdlib-android:ktx:0.1.1") }
val client = TdClient(filesDir = context.filesDir .absolutePath + "/tdlib") client.init() CoroutineScope(Dispatchers.IO).launch { client.updates.collect { /* handle UpdateNewMessage */ } }
Nothing ships from a laptop. Every release passes through the same four gates, automatically, before a human ever clicks merge.
A scheduled workflow watches TDLib master every 6 hours and triggers on change.
All 4 native architectures compile in parallel with a pinned NDK r27c.
ELF headers are validated with readelf -h, never by file size. Partial ABI sets are rejected.
An automated PR carries the full diff plus SHA-256 checksums. Merging publishes signed AARs straight to Maven Central.
Four ABIs of libtdjson.so with TdApi.java, Client.java and R8 consumer rules shipped inside the AAR itself.
Updates as Flow<TdApi.Update>. Thin bridge, ~150 lines, no app logic.
Version bumps land as review-ready PRs with diff and checksums. You never chase TDLib releases.
16KB page alignment verified per-build, forward compatible with target SDK 35.
Clone, open, run. The shortest path from zero to a connected TDLib client.
Compiling TDLib once takes an hour of NDK setup and 4 toolchains. This repo exists so you never do.
| tdlib-android | DIY compile | Self-hosted CI | |
|---|---|---|---|
| All 4 ABIs | ✓ every release | manual per-arch | ✓ |
| Local NDK needed | never | yes, 4 toolchains | docker only |
| 16KB page alignment | verified in CI | your job | your job |
| Upstream tracking | automatic, 6h | manual | manual |
| Binary verification | readelf gate | — | — |
| Distribution | Maven Central | manual | manual |
Current release 0.1.1 (TDLib 1.8.x), signed and checksummed.