Signal Android, the Kotlin client behind a three-release week

Two Android channels, three separate codebases

The Android app is distributed two ways: the Play Store listing under `org.thoughtcrime.securesms`, and a direct APK linked from signal.org. Two channels, one codebase, and a beta track on the Play Store.

What is in this repository is the Android client and nothing else. The README points at separate repositories for iOS and for Desktop, so a capability that lands on Android here is not automatically in the other two, and reading one repository tells you nothing about the state of the other platforms.

The functional description in the README is short on purpose: the app communicates over the phone's own data connection on WiFi, 4G or 5G, sends high-fidelity messages, carries HD voice and video calls, and keeps its privacy-preserving technology enabled rather than optional. There is no server component described here, because this repository is the client, and the messaging service itself is not what you are looking at when you clone it.

build-logic, fast-lint and lefthook are the project's own tools

The build is Gradle, driven by the checked-in `gradlew` and `gradlew.bat` wrappers with `settings.gradle.kts` and `build.gradle.kts` at the root. Kotlin is the primary language, and the source is split into `app/`, `core/`, `feature/`, `lib/` and `wire-handler/`, which is the shape to look at first when you want to know where a change belongs.

The repository carries more of its own tooling than most. `build-logic/` holds the build configuration, `fast-lint/` and `lintchecks/` sit next to a `lint.xml` configuration file, and `lefthook.yml` wires checks into git hooks. There is a `.tool-versions` file, so the toolchain is pinned rather than whatever your machine happens to have.

For a contributor that means the setup is not a one-command affair: the pinned toolchain, the wrapper and the local lint rules are the entry requirements. The upside is that a change that violates the project's own conventions is caught before review rather than in it.

demo/ is a directory of single-feature modules

The most useful directory in the repository for orientation is `demo/`, which holds one module per feature surface: apng, camera, contacts, debuglogs-viewer, device-transfer, donations, image-editor, list-detail, media-keyboard, paging, qr, registration, spinner and video.

Read as a map, that list is a statement about how this client is organised. Registration, QR, device transfer and contacts are each a self-contained area, which is where a first-time contributor learns where things live. Debug log viewing and a debuglogs-viewer module also tell you the app has a support story, matching the README's pointer to the support centre for troubleshooting.

Microbenchmarks and baseline profiles live in the same build

Performance work is not in a separate repository either. `microbenchmark/`, `benchmark/` and `baseline-profile/` are all present at the top level, alongside a `reproducible-builds/` directory and a `pkcs11.config` file.

That grouping is the Android tooling model rather than a Signal invention, and it does tell you what the project expects of a change: a modification to a hot path can come with a microbenchmark and a baseline profile update in the same pull request, and the build is set up to produce reproducible output so two builds can be compared.

A contributor who plans for it treats a performance change as three pieces of work, the code, the measurement, and the profile that ships with it.

New contributors are told to fix a bug first

The contributing guidance is unusually specific. GitHub is used for bug tracking, and you are asked to search the existing issues before creating a new one. If you are new to the codebase, the README recommends picking out a simple bug to fix in order to get familiar with it, with CONTRIBUTING.md as the reference for the rest.

Larger changes and feature ideas go somewhere else first: the project asks that they be proposed on the unofficial Community Forum for a high-level discussion with the wider community before implementation. Translations are collected through the same community site, and the forum is also where general conversation happens.

So the order of operations matters. A patch that matches an open issue is the cheap route. A feature proposal submitted as a pull request is the expensive one, because the project wants the design conversation to happen off the tracker first, and the forum it points at is, in its own words, unofficial.

Three tagged releases in five days, and a beta you opt into

The release line moves fast. The tags show v8.34.0 on 2026-10-28, v8.34.1 on 2026-10-29 and v8.34.2 on 2026-10-30, and the repository's last push was on 2026-10-30. The repository is not archived.

That cadence is what makes the beta track matter. Joining the beta is a Play Store testing subscription for `org.thoughtcrime.securesms`, and subscribing replaces the standard build on the device with whatever the tester channel currently serves. The README's own framing is blunt about the choice: take the beta if you want to live on the bleeding edge and help test, stay on standard releases otherwise.

For a user on an older phone, that is a real decision rather than a preference. A channel that ships v8.34.0, v8.34.1 and v8.34.2 within three days is also a channel where a regression reaches you before the next patch, which is exactly what the standard track exists to avoid.

AGPL-3.0 and an export classification in the same README

The licence is the GNU AGPLv3, with copyright held by Signal Messenger, LLC since 2013, and the LICENSE file at the repository root. For anyone considering reuse rather than contribution, that is the term to read first, because the AGPL reaches beyond the case where you merely run the app.

The README also carries a cryptography notice, and it is about law rather than about features. It states that the country you reside in may restrict the import, possession, use and re-export of encryption software, asks you to check your own regulations before using it, and links to the Wassenaar arrangement. It records that the US Department of Commerce Bureau of Industry and Security classifies the software as Export Commodity Control Number 5D002.C.1, covering information security software using asymmetric cryptographic functions, and that the distribution is eligible for export under License Exception ENC Technology Software Unrestricted, Section 740.13 of the BIS regulations, for both object code and source code.

The notice is about import and export law. It says nothing about network availability in any particular country, so it is not a source for questions about reachability.

Editorial conclusion

Signal Android is worth reading if you want to see how a privacy-first messenger is built in Kotlin, with a Gradle layout where app, core, feature, lib and wire-handler are separable, or if you plan to contribute a fix. It is the wrong repository for a fork you intend to ship under different terms, because the code is AGPL-3.0, and the wrong place to look for a cross-platform feature, since iOS and Desktop live in their own repositories. Before opening a pull request, read CONTRIBUTING.md and check the issue tracker, and for anything larger than a bug fix, take the proposal to the community forum first.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. signalapp/Signal-Android on GitHub