threema-ch/threema-android: a complete messenger source, published one commit per release

Published in full, one commit per release

This repository contains the complete source code of Threema for Android, and the release policy is unusually explicit about how that source is kept in step with the shipped app.

The source code repository will be updated for every public non-beta release, with one commit per released version, and the commits are signed using PGP, with SECURITY.md carrying more information about that.

That is a meaningful design decision for a commercial messenger. Most commercial applications with open source clients either publish a snapshot that drifts from the product, or publish a history that is hard to map onto a specific release. One signed commit per version means you can check out the tree that produced a particular build, and that a change in behaviour is a change you can diff against a specific tag.

The project is AGPL-3.0 licensed and the code is in Kotlin, with a Gradle build, and the whole point of publishing it is auditability, since a messenger whose security claims are worth anything has to be checkable by people who are not the vendor.

Four license checks, and the line a self-built app cannot cross

The licence checks section is the part of the README that surprises people, and it deserves close reading.

The source code is published under an open source licence, but Threema is still a paid app, and to run the app in combination with the official server infrastructure you must have bought a licence, either on Google Play or in the Threema shop.

For a Google Play purchase, the app sends an LVL licence verification token to the directory server, which lets the server verify that you bought the app without being able to identify you. The consequence is stated directly. A self compiled app using the `google` build variant cannot be used to create a new Threema ID. What you can do is use an app that was purchased over Google Play to create an ID, export a backup, and then import that backup into the self compiled app. The note that the ID creation endpoint is monitored for abuse is there for a reason.

The Huawei AppGallery purchase works the same way with a Huawei DRM Signature sent to the directory server, and the same limitation and the same backup round trip apply to the `hms` variant.

If you bought a Threema for Android licence in the Threema Shop you received a licence key, and that key is what the `store_threema` build variant uses for verification. For the `work` build variant you must provide credentials from a Threema Work subscription. And the `none` variant, used for development, can only create new Threema IDs if the random Device ID has been put on an allow list by a Threema employee.

So the open source is the client, the service is the paid part, and the client is engineered so that a self compiled build is a genuine client without being a way around the purchase.

The flavour matrix

The build variants section is a table of product flavours, each with its own licence check, and it is a good picture of how a commercial Android app is actually shipped.

For the private version the flavours are `store_google` for the Google Play Store version, `hms` for the Huawei AppGallery version, `store_threema` for the Threema Shop version with play services, and `libre` for the F-Droid version with no proprietary code. For local testing the recommendation is to build the `store_google` or `store_threema` variants.

The footnote on `store_threema` and `libre` is the interesting one. The main difference is that the former contains proprietary push services and a self updater while the latter does not, and additionally the `libre` version uses your system emoji instead of bundling emoji graphics. That is a small thing that says a lot about how much proprietary code a fully free build can avoid.

There is a second set for Threema Work and OnPrem customers, with `store_google_work`, `hms_work` and `onprem`, all checked against a Threema Work subscription. And a third set for internal development and testing, `none`, `green`, `sandbox_work` and `blue`, all using the allowlist, with the green, sandbox_work and blue ones pointed at a sandbox backend that is a backend test environment used for internal testing and that cannot currently be accessed from the public internet.

That last point has a practical consequence for anyone who wants to run the app against a test backend. The sandbox is not reachable from outside, so a self builder is limited to the `none` flavour and the allowlist, or to the real servers with a purchased licence.

Building it needs the Android toolchain and Rust

The building section starts by telling you to read the build variants section first, which is sensible, because the flavour you pick determines the licence check you will hit at runtime.

The command line prerequisites are listed as the Android SDK, the Android NDK, a bash shell, the protobuf compiler and Rust.

Rust in that list is the one that tells you something about the codebase. A messenger written in Kotlin does not normally need a Rust toolchain, so the Rust dependency implies a native component, which is the usual reason the NDK is there too, and the protobuf compiler implies the wire format is defined in schema files rather than in hand written serialisers. Both of those are design choices with real benefits, a Rust component for the cryptography and the protocol handling, and a schema definition for a message format that has to stay stable across app versions and across the other clients in the family.

The repository structure follows the same modularity. There is `domain/` for the domain logic, `common/` and `commonAndroid/` for shared code, `app/` for the Android application, `plugins/` for the modular features, `buildSrc/` for the Gradle build logic, `lint-rules/` for custom lint checks, `test-helpers/` for the test utilities, and `scripts/` for the build scripts. There is a `stability_config.conf` and a `contributors.csv`, and a `THANKS.md` alongside the `SECURITY.md`.

Security issues, the bug bounty, and where to report what

The issues section splits three kinds of report into three channels, which is the correct thing to do and worth copying.

For bugs and feature requests you contact the Threema support team through threema.com/support.

For a security issue, the instruction is to adhere to the coordinated vulnerability disclosure model, and to be eligible for the bug bounty you file a report on GObugfree, where the details including the bounty levels are listed. If you are not interested in the bounty programme you can contact the company via Threema or by email, with the contact details in the security section of the contact page.

The distinction between the two security channels is a small piece of security process design that many open source projects get wrong. A coordinated disclosure report and a public bug report need different handling, and offering a bounty with published levels gives a researcher a reason to report privately rather than opening an issue.

Where this is the wrong project

The first wrong case is a team that wants to run their own messenger on their own infrastructure from this source. The code is published, but the service is not. The directory server, the push services, the key infrastructure and the account system are the product, and the client is a client for them, so a self compiled build is a client that talks to somebody else's servers and that you have paid for.

The second is a team that wants to rebrand it. AGPL-3.0 permits modification, and the `libre` flavour shows the project is comfortable with a build that carries no proprietary code, but the licence check and the server side are unchanged, so the result is a free client for a paid service, which is not a fork in any useful sense.

The third is an evaluator who wants a quick security review. The per release commit history is excellent for that, but the build is heavy, and the readme points you to the wiki for architecture, so an audit of this client is a multi day task rather than an afternoon one.

The fourth is a team looking for a general purpose messaging library. This is an application, not a component, and the `domain/` and `app/` separation is an internal structure rather than a public API.

On the state of the project, the repository is not archived and the last push was on 2026-09-23, and the release list is empty because releases are made through the app stores rather than as GitHub releases. The source is published under AGPL-3.0 with the open source page at threema.ch/open-source, and the contributions model is the unusual one this project is built around, complete source with a signed commit per release, a bug bounty for security work, and the rest of the interaction through the support team and the forum.

Editorial conclusion

Adopt this repository if you want to read, audit or build the Threema messenger for Android, since the whole source is published with a per release commit history and signed tags, which makes it a rare example of a commercial closed service shipping its complete client source. Do not expect a self compiled build to be a drop in replacement, because the licence check means a build from source cannot create a new ID, and the ID creation endpoint is monitored for abuse. Verify first which build flavour you need, since the choice determines the licence check you will face, that the licence key or subscription credentials you need are in place before you try to register, and that the commit you build is the one signed for the release you intend to run.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. threema-ch/threema-android on GitHub