# Element X Android: a Matrix client built on the Rust SDK and Jetpack Compose > Element X Android is Element's rewrite of its Matrix client for Android 7 and above, with the Matrix Rust SDK behind an FFI layer and a Compose UI. Here is what the repository documents, what it leaves open, and who should build on it. **element-hq/element-x-android** — Android Matrix messenger application using the Matrix Rust Sdk and Jetpack Compose - Repository: https://github.com/element-hq/element-x-android - Stars: 2,423 · Forks: 656 - Language: Kotlin - License: AGPL-3.0 - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/element-hq-element-x-android ## The problem Element X Android addresses: one client, two generations Element shipped a Matrix client for Android for years. That client, now referred to in the README as Element Classic, accumulated its protocol handling, encryption and UI in Kotlin. Element X Android is the replacement, and the README is explicit that it is "a total rewrite" rather than a refactor. The audience is twofold. End users are pointed at it directly: "New users are recommended to use Element X instead of the previous-generation app." Developers are the second audience, and the repository is laid out for them, with separate top-level directories for app, features, libraries, services, appnav, plugins and enterprise rather than a single monolithic module. The practical consequence of the rewrite is that the client is no longer the place where Matrix semantics are implemented. That work moved down into the Matrix Rust SDK, and Element X Android consumes it. If you are choosing a Matrix client to fork, this is the decision that matters most: you inherit a thin Kotlin layer over Rust instead of a large Kotlin codebase that implements the protocol itself. ## How the Rust SDK, FFI layer and Compose UI fit together The README describes the architecture in one sentence: Element X leverages the Matrix Rust SDK "through an FFI layer that the final client can directly import and use." That layer is the boundary. Above it sits the Kotlin application, whose UI is written in Jetpack Compose and whose navigation is managed by Appyx, a third-party library from Bumble. Below it sits the Rust SDK, which is where the shared code lives. The stated motivation is code sharing across platforms, and the README is candid about where that stands: "while we've seen promising results it's still in the experimental stage and bound to change." Treat that as a design constraint, not a disclaimer. An FFI boundary that is still changing means the Kotlin side cannot assume a frozen interface, and a fork that reaches below the boundary inherits the churn. The repository layout reflects the split: codegen and annotations directories at the top level suggest generated bindings are part of the build, and the separate app and enterprise directories indicate more than one application target is built from the same feature and library modules. The navigation choice is worth noting because it is unusual. Appyx is not the default Android navigation stack, so contributors arriving from a standard Compose project will need to learn a different model for back stack and transition handling before touching screens. ## Installing Element X Android and building the app configuration For users, the README points at two distribution channels: the Google Play listing under the package id io.element.android.x, and the F-Droid package of the same id. There is no self-hosted download page documented in the README, so those two stores are the paths the project itself gives. For developers, the build instructions are deliberately short. Clone the repository and open it in Android Studio. The one trap the README calls out is the build target: "Make sure to select the app configuration when building (as we also have sample apps in the project)." Building the wrong configuration is the most likely first-run mistake. The default branch is develop, and the build status badge in the README is scoped to that branch, so that is the branch to start from. The project uses the Gradle wrapper, and gradlew and gradlew.bat are present at the top level, so no separate Gradle installation is needed. If you need to build against a local copy of the Rust SDK rather than the published artifact, the README does not repeat those steps; it delegates to docs/_developer_onboarding.md, section "Building the SDK locally". That document is the source to read before attempting it. The README also notes the minimum SDK: version 24, which is Android 7.0 Nougat. A separate enterprise variant requires minimum SDK 33, Android 13 Tiramisu. ## Where Element X Android is the wrong tool The clearest limitation is stated by the project itself. The Rust SDK integration is described as experimental and "bound to change." If you are building a product that depends on a stable client SDK contract, that sentence should stop you. A fork pinned to a moving FFI boundary carries upgrade work that a self-contained Kotlin client would not. The second limitation is the enterprise boundary. Element Android Enterprise requires minimum SDK 33, and the README gives the reason: for Element Enterprise, only devices that still receive security updates are supported. An organisation with a fleet of Android 7 through 12 devices can run the consumer app but not the enterprise variant. That is a hard split, not a configuration flag. The third is documentation depth. The README covers translations, build instructions and support channels, but it does not document rollback, release cadence policy, or how the app behaves when the Rust SDK version and the Kotlin layer are out of step. Where the README is silent, the repository files are the only source, and that means reading the Gradle files yourself. Finally, the translation workflow is partially closed. Anyone can join the Localazy project, but the README states that French and German translations are kept under the project's control. If your deployment needs to correct a French or German string, you cannot do it through the community translation path. ## Element Classic compared with Element X Android The comparison the README invites is with Element Classic, the previous-generation client at element-hq/element-android. The difference is not cosmetic. Element Classic implements Matrix in Kotlin, so the protocol and encryption logic sit in the same language as the UI and can be read, patched and debugged in one place. Element X Android pushes that logic into the Matrix Rust SDK and reaches it through FFI, which means the same core can serve other platforms, and the README frames code sharing as the reason for the design. The trade is visibility. In Element Classic, a bug in message handling is a Kotlin bug in the repository you cloned. In Element X Android, the same bug may live below the FFI boundary in a different repository, and the README's own wording about the experimental stage suggests that boundary is still settling. For a team that wants to read every line of the stack, Element Classic is the more transparent codebase. For a team that wants the newer client and is willing to track the SDK, Element X Android is where Element is directing new users. The UI story differs too. Element X Android uses Jetpack Compose with Appyx for navigation, which is a modern Android stack but a less common one. Element Classic predates that combination. ## Maintenance, releases and what AGPL-3.0 means here The repository is not archived, and the last push was on 2026-09-28. Releases are frequent and versioned by date: v26.09.1 on 2026-09-01, v26.09.2 on 2026-09-10, v26.09.3 on 2026-09-25. Three releases in a month is a real upgrade cadence, and it means a fork that wants to stay close to upstream will be rebasing often. The licence is AGPL-3.0, and the README's final section is titled "Copyright and License". A separate top-level file, LICENSE-COMMERCIAL, sits alongside LICENSE in the repository. The presence of a commercial licence file means the project offers more than one licensing path, and the terms of that path are not summarised in the README. If you intend to ship a modified Element X Android in a context where AGPL-3.0 obligations are a problem, read LICENSE-COMMERCIAL directly. This article is not legal advice, and the licence text governs. The upgrade cost is concentrated in two places: the Rust SDK version you build against, and the FFI bindings that connect it to Kotlin. Because the README describes that layer as still changing, budget for reading the diff on the SDK side, not only the Kotlin side, on each upgrade. ## Conclusion Adopt Element X Android if you want a Matrix client whose protocol and crypto work lives in the shared Rust SDK rather than in Kotlin, and if you can work with an FFI layer the README itself calls experimental. Do not adopt it if you need a stable SDK contract, a supported path to build against your own Rust SDK copy without reading docs/_developer_onboarding.md, or an Android Enterprise deployment below Android 13, since the enterprise variant requires minimum SDK 33. Verify first that your build produces the app configuration and not one of the sample apps, and check the LICENSE-COMMERCIAL file before assuming AGPL-3.0 is the only option you have. ## FAQ ### Is the Element X Android app safe? The repository does not make security claims about the app itself. What it does state is that the client is built on the Matrix Rust SDK through an FFI layer, and that this integration is still in the experimental stage and bound to change. For distribution, the README points to Google Play and F-Droid under the package id io.element.android.x. ### Which is better, Element Classic or Element X Android? The README recommends Element X for new users and describes it as a total rewrite of the previous-generation Element Classic. The practical difference is that Element Classic implements Matrix in Kotlin, while Element X Android relies on the Matrix Rust SDK behind an FFI layer, which the README says is still experimental. ### Does Element have a mobile app? Yes. Element X Android is the Android client, and the README links to Google Play and F-Droid listings under io.element.android.x. It supports devices running Android 7.0 and above, with a minimum SDK version of 24. ### Does Element X Android work on Android? It is an Android application. The README gives a minimum SDK version of 24, which is Android 7.0 Nougat, and says the project aims to support Android 7.0 and above. A separate enterprise variant requires minimum SDK 33, Android 13. ## Sources - [element-hq/element-x-android on GitHub](https://github.com/element-hq/element-x-android) - [Issues](https://github.com/element-hq/element-x-android/issues) - [License: AGPL-3.0](https://github.com/element-hq/element-x-android/blob/develop/LICENSE) - [README](https://github.com/element-hq/element-x-android/blob/develop/README.md) - [Releases](https://github.com/element-hq/element-x-android/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/element-hq-element-x-android