# Session Android: a messenger that stores messages off the device

> Session is a private messenger whose messages are stored on Oxen Service Nodes rather than on a central server, with onion routing to obfuscate the addresses of the participants. It fits people who want a messenger that does not run on a company server, and it does not fit a team that needs message retention under its own control or a synchronous working phone with contacts and history already in place.

**session-foundation/session-android** — Session Android - A Decentralized, Onion Routed, Private Messenger

- Repository: https://github.com/session-foundation/session-android
- Website: https://getsession.org
- Stars: 928 · Forks: 113
- Language: Kotlin
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/session-foundation-session-android

## Messages live on the network, not on a server you can subpoena

Session is described as a decentralized, onion routed, private messenger for Android. The mechanism behind that description is Oxen Service Nodes, which the documentation describes as a set of distributed, decentralized and Sybil resistant nodes. Two roles are given for them. Service Nodes act as servers which store messages offline, and a set of nodes allow for onion routing functionality obfuscating users' IP addresses.

That is the whole architectural difference from a conventional messenger. In most chat applications the operator of the service holds the messages, which means the operator can be compelled to hand them over, or can lose them, or can be bought. Here the messages are stored off the device on a distributed set of nodes, and the addresses of the participants are obscured by onion routing rather than exposed to a single party.

The trade is real and it is not hidden by the project's own framing. If nobody holds your messages centrally, then nobody can hand you back a complete history either. The Session Whitepaper is linked from the repository for the full explanation of how the pieces fit together, and ARCHITECTURE.md at the repository root is the document to read if you are a developer, since it gives an overview of the important parts of the code and how they fit together.

The application code is Kotlin, built with Gradle, with the app/ directory holding the application, common/ for shared code, content-descriptions/ for localisation resources, build-logic/ for the Gradle convention plugins, and an etc/ directory of supporting material.

## Three ways to get the app, and they are not equivalent

The repository lists three distribution routes, and a user comparing them should know what separates them.

The first is the Google Play Store, linked from the project site. The second is an F-Droid repository at fdroid.getsession.org, which is the route for anyone who does not want the Play Store's distribution model. The third is a direct APK download from the GitHub releases page.

The third route is where the repository does something careful. The README lists SHA-256 certificate fingerprints for each distribution channel separately, and they differ, because the Play build and the GitHub build are not byte-identical.

For the GitHub APKs with the play-release suffix, the fingerprint is F2:A0:EC:F7:06:86:44:7D:1D:6C:6C:BB:F5:8C:42:89:05:00:CC:F4:1A:F3:72:AE:20:99:30:39:80:82:4E:DD. The GitHub Huawei build carries C6:F5:19:DE:2B:98:D3:A2:B7:76:5C:52:F6:2D:9E:2F:94:51:D9:9C:EE:D2:F3:7B:95:CB:96:22:92:8E:8F:67. The Google Play build is A0:22:5A:4A:C3:3A:76:E6:7D:B2:73:ED:17:D7:D6:CF:BB:AE:2B:4F:95:07:42:86:4F:83:F4:13:DE:0C:5B:E5.

The package ID across all of them is network.loki.messenger, which is a historical name worth recognising when you are checking what is actually installed on a device.

## Verifying a release signature in four steps

The repository documents signature verification in enough detail to be followed without guessing, and for a messenger this is the part worth reading.

The signer for all Session Android releases is Jason Rhinelander, a member of the Session Technology Foundation, and the process starts with his GPG key:

```
wget https://github.com/jagerman.gpg
gpg --import jagerman.gpg
```

Next you fetch the signed hashes for the release you want. The documentation notes that SESSION_VERSION needs to be updated for the release you are verifying, and shows 1.20.8 as the example:

```
export SESSION_VERSION=1.20.8
wget https://github.com/session-foundation/session-android/releases/download/$SESSION_VERSION/signature.asc
```

Then you verify the signature of the hashes:

```
gpg --verify signature.asc 2>&1 |grep "Good signature from"
```

The documentation says the output should print a good signature from Jason Rhinelander, and adds a point that is easy to miss. A good signature means the hashes are valid, but you still have to confirm that the signed hashes match the files you actually downloaded. The last step is that comparison:

```
sha256sum session-$SESSION_VERSION-universal.apk
grep universal.apk signature.asc
```

If both commands return the same hash for the file you are checking, the file is valid. Two independent checks, one for the signer and one for the file, and the second is the one that catches a tampered download.

## Building from source and the dev branch

Build instructions live in RELEASE.md rather than in the README, which tells you the build is a release-engineering document rather than a getting-started guide. The repository layout is a modern Gradle Kotlin DSL project: build.gradle.kts and settings.gradle.kts at the top level, a gradle/ directory with the wrapper, gradlew and gradlew.bat for Unix and Windows, and build-logic/ for the convention plugins that the modules share.

There is a gradle.properties file and a .gitmodules entry, so some dependencies are pulled in as submodules rather than through a package registry. Continuous integration is defined in .drone.jsonnet and .drone.yml, using Drone rather than a hosted CI product, and the project also carries a .run/ directory, which is the JetBrains IDE run-configuration format, so contributors are expected to work in IntelliJ or Android Studio.

The contribution model is stated plainly. Bug reports and feature requests go through GitHub issues, and the instructions ask you to search the existing issues first to avoid duplicates. Pull requests go to the dev branch, which is also the default branch of the repository, and the README suggests reading the issues page for ideas if you do not know where to start. That is a normal open source workflow with one notable property: dev is where work lands, so a build from the default branch is a build of unreleased code.

Testing is done with BrowserStack, and the repository notes this project is tested with it. For an application that depends on web views and platform behaviour, running the suite against real devices in the cloud is a reasonable choice, and it also means contributors without a physical Android device can still exercise the app.

## A licence history that mirrors the project's ownership

The licence is GPLv3, and the copyright notices in the repository trace the ownership of the code across four eras: Copyright 2011 Whisper Systems, Copyright 2013 to 2017 Open Whisper Systems, Copyright 2019 to 2024 The Oxen Project, and Copyright 2024 to 2025 Session Technology Foundation.

Those dates line up with the technical story. The app began as Whisper Systems, then Open Whisper Systems, which is the lineage behind the original Whisper messenger and the Lokinet-era work, then moved to the Oxen Project, which is the same organisation behind the Oxen blockchain and its Service Nodes, and since 2024 into the Session Technology Foundation.

For a user, the practical consequence of GPLv3 is that the application is free software and its source is in this repository. For a developer considering reuse of code from the app, the obligations of the GPLv3 attach to the code, not to the fact that the messenger is used for private communication.

One third-party attribution is named. The project uses the Lucide Icon Font, licensed under the ISC License, with the licence text kept in third_party_licenses/LucideLicense.txt. That directory in the repository is where the other attributions live, and the presence of an etc/ directory and a separate FDROID_RELEASE.md document shows the project keeps the F-Droid build as a first-class target rather than an afterthought.

The organisation behind the project also has a translation programme, with a page at getsession.org/translate for contributors, and a code of conduct document in the repository.

## Where this messenger does not fit

The honest limitation of the design is that a messenger without a central operator is a messenger without a searchable, exportable, archivable history held by one party. If your organisation needs to retrieve a conversation from three years ago for a legal hold, or to hand a departing employee's messages to a successor, this architecture does not give you that, and the project does not claim it does.

The second limitation is the one every non-mainstream messenger faces. The documentation in this repository is an install and verification guide, not a feature catalogue. There is no description here of group messaging, calls, file transfer, reactions, message editing, or how the desktop client works, so anyone evaluating Session should expect to read the whitepaper and the product site for the feature set rather than this file.

A third, more concrete point for anyone building on the code: the Service Nodes are the dependency. The messaging experience depends on a set of nodes being operated and reachable, and the onion routing layer depends on that network functioning. The Service Nodes are described as Sybil resistant, which is the property that keeps the storage honest, but the same network is a single point of failure for the whole product in a way that a server you control is not.

None of that makes the project wrong for its audience. It makes it a specific choice rather than a general-purpose WhatsApp replacement, and it should be evaluated as one.

## Conclusion

Adopt Session if your requirement is that no single operator holds a copy of the conversation, and you are prepared for an app whose history does not arrive pre-populated with your existing contacts and threads. Skip it if you need an organisation to be able to retrieve and export message history, if you need the full feature set of a mainstream messenger, or if the browser-based desktop client is a requirement. Verify first that the build you install matches one of the published SHA-256 fingerprints, and check the signature with the documented gpg commands before you trust an APK from a mirror.

## FAQ

### How do I download Session for Android?

The project is available on the Google Play Store, through an F-Droid repository at fdroid.getsession.org, and as a direct APK from the GitHub releases page. The SHA-256 fingerprint differs between those channels, so check the one that matches the build you installed.

### How do I verify a Session Android release signature?

Import Jason Rhinelander's GPG key with wget https://github.com/jagerman.gpg and gpg --import, download signature.asc for the release, run gpg --verify signature.asc and look for a good signature, then compare the sha256sum of the downloaded APK with the hash in signature.asc using grep.

### Where are Session messages stored?

The documentation states that Session integrates with Oxen Service Nodes, which are distributed, decentralized and Sybil resistant nodes. Service Nodes act as servers storing messages offline, and a set of nodes provides onion routing to obfuscate users' IP addresses.

### Which licence is Session Android released under?

It is licensed under the GPLv3. The copyright notices in the repository record Whisper Systems from 2011, Open Whisper Systems from 2013 to 2017, The Oxen Project from 2019 to 2024, and the Session Technology Foundation from 2024 to 2025.

## Sources

- [License: GPL-3.0](https://github.com/session-foundation/session-android/blob/dev/LICENSE)
- [Project website](https://getsession.org)
- [README](https://github.com/session-foundation/session-android/blob/dev/README.md)
- [Releases](https://github.com/session-foundation/session-android/releases)
- [session-foundation/session-android on GitHub](https://github.com/session-foundation/session-android)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/session-foundation-session-android