Can I use Offline Protocol in a native Kotlin Android app?

A native Kotlin Android app can use Offline Protocol through the Android library com.offlineprotocol:offline-protocol-sdk on Maven Central, which is a preview as of 0.31.0 (October 2026). It needs no React Native: it is built from the React Native module’s Android sources, less the files that need React, so it carries the same transport managers and storage classes. What is public in it is what that module needed public, so the generated API may change in a later release.

The library is on Maven Central from 0.29.0 onward and is published with every SDK release. Every channel carries the version number of the release it came from, so offline-protocol-sdk 0.31.0 on Maven Central is the same release as @offline-protocol/mesh-sdk 0.31.0 on npm and offline-protocol-sdk 0.31.0 on PyPI. For a phone app you ship today, the Offline Protocol docs recommend the React Native package, which ties transports and storage to the engine for you. The Swift package is at the same preview stage on iOS.

Add Maven Central to your repositories, if it is not there already, and the library to the app module:

dependencies {
    implementation("com.offlineprotocol:offline-protocol-sdk:0.31.0")
}

The library depends on JNA as an Android archive, because the generated Kotlin types extend JNA’s, and Gradle adds it for you. Artifacts are signed with the Offline Protocol release key, fingerprint 55FD B6AB C147 BD60 9EE0 447D C671 8335 845D 9497. The library is dual-licensed: AGPL-3.0-only, or a commercial licence.

The library’s floor is Android 7 (API 24), and the docs give its compile level as API 34. That is the same floor as the React Native package.

The library ships the native library for four ABIs: arm64-v8a, armeabi-v7a, x86 and x86_64. A release build of the library is checked to contain all four, and the check refuses a native library under any other name.

For builds that cannot use Maven Central, each GitHub release also attaches offline-protocol-X.Y.Z-android.zip. It holds only the generated Kotlin bindings (uniffi/offline_protocol/offline_protocol.kt, which call the library through JNA) and the native libraries for the same four ABIs, without the Android transport and storage classes.

The AAR on Maven Central has three parts:

The native library is the same Rust engine the other bindings use. It queues, routes and encrypts with MLS (RFC 9420), and the transport managers do the radio and network I/O on its behalf. The Kotlin bindings are generated from the same interface definition as the Swift, Python, Ruby and Java bindings, in one step, so the API a Kotlin app calls matches theirs.

The library also takes the module’s R8 consumer rules, so an application can minify a release build. That path is part of the library’s own checks: a separate consumer app depends on the published coordinates, declares nothing else, and builds a minified release. Values such as the minimum SDK, the dependency versions and the manifest are read from the React Native module at build time, so the two packages do not drift apart.

A Kotlin app connects the pieces to the engine itself, because the React Native module that does that job is not part of the library. The steps are:

• Wire the transports. Connect the Bluetooth LE, Wi-Fi Direct and internet managers to the engine.
• Wire the storage. Hand the included storage classes to the engine.
• Request runtime permissions. The library’s manifest already declares the Bluetooth, Wi-Fi, INTERNET and network-state permissions the transports need; your app requests the runtime ones, such as BLUETOOTH_SCAN, BLUETOOTH_CONNECT and BLUETOOTH_ADVERTISE on Android 12 and later. Bluetooth permissions on Android, explained covers each one.
• Declare location for older Android. Add ACCESS_FINE_LOCATION if you support Android 12 or lower, where Bluetooth LE scanning (11 and lower) and Wi-Fi Direct discovery (12 and lower) need it.
• Plan background restarts. The library’s manifest leaves out the React Native module’s wake service and WAKE_LOCK, so the optional mesh wake that React Native apps can turn on is not included.

The transport code is the same code the React Native module runs, so the same reach applies. An Android phone reaches other Android devices in a Wi-Fi Direct group, and iPhones and Python hosts on a shared Wi-Fi network that allows multicast. Bluetooth LE or a relay connects them anywhere else.

Pick React Native when you are shipping an Android or cross-platform app now. @offline-protocol/mesh-sdk has the same Android floor (API 24), declares its own permissions, wires Bluetooth LE, Wi-Fi Direct and peer streams, the relay and storage to the engine, and is the stable integration.

Pick the Android library when your codebase is native Kotlin and you want to evaluate the engine there, build on the generated bindings directly, or follow the native API as it settles. Expect to write the transport and storage wiring, and to update code when generated names change. For a desktop or server JVM, the separate Java binding is the package to use, and Which Offline Protocol SDK should I use? compares every binding.