joplin-android: where the Joplin APKs live, and which one your phone needs

A build output repository, not a source repository

The joplin-android repository hosts only the Joplin APK files, and the README is explicit that this is a hosting arrangement rather than a codebase. The source code is at a different repository, laurent22/joplin, and the Google Play page is listed separately as well.

The split exists for a reason that the README does not spell out but that the arrangement makes clear. Building the Android app produces artefacts that people want for reasons that have nothing to do with the source: a build that is newer than the Play Store rollout, a build that has not passed store review yet, or a build for an architecture the store distribution does not cover. Keeping those binaries in their own repository separates them from the code that produces them, which means a tag here points at a build rather than at a commit of the application.

That also explains the small size of the repository. The top level listing is just README.md and test.md, plus the release artefacts attached to the tags. There is no build system here, no configuration and no script to run. It is a distribution point.

The homepage recorded for the repository is the Joplin site at joplinapp.org, and the topic tags are android-releases and joplin, which is a description of the repository's role rather than its technology.

Do not go to the releases page, go to the tags page

The first practical instruction in the README is about a GitHub behaviour rather than about Joplin. GitHub has a won't fix bug in the way it sorts releases, so you are told not to go to the release page, and instead to go to the Tags page, where they will be sorted in the correct order.

This is the kind of detail that saves real time. A repository of release binaries is exactly where a sorting bug does damage, because the whole point of the page is to let you find the newest build. If you arrive at the releases tab and the order is wrong, it is easy to conclude that the project has stopped shipping and to install an old build. The tags view is unaffected.

The URL to use is:

https://github.com/laurent22/joplin-android/tags

The changelog is linked separately, on the Joplin documentation site at the help/about/changelog/android path, so the version history lives with the project documentation rather than in the repository. That separation is consistent with the rest of the arrangement, where the repository holds binaries and the site holds the explanation.

Most of these builds are pre-release, and the README says so up front

The README tells you to assume that most of the releases are pre-release unless the tag is marked as latest, and it links the Joplin documentation on pre-releases.

That is a load-bearing warning, because a repository that hosts Android binaries is where people go when they want something that is not the store version. Pre-release builds are exactly what most of those people are looking for, and also exactly the kind of build where an unexpected behaviour is a bad surprise.

The distinction matters more on Android than on a desktop. An app installed from an APK outside the Play Store skips the store's rollout and staging, so you can be the first person on a build that has not been exercised widely. The README's guidance is to check whether the tag is marked as latest, which is the only signal in the repository itself.

The release history in the repository shows a pattern worth noting. There is android-v3.7.8 dated 2026-09-05, android-v3.7.10 dated 2026-09-10, and android-v3.6.22 dated 2026-08-20. So the 3.6 line was still receiving builds in late August while the 3.7 line was producing patches in September, and the 3.7 patches continued past the release of 3.7.8. If you need a specific line, that is the information the tags page gives you.

One APK for every architecture, or a prefixed one for yours

The architecture guidance is the most useful part of the README, and it starts with a simple offer. If you do not know your phone's architecture, you can install the version without the joplin-vX.Y.Z.apk prefix, as it includes all the architectures. Otherwise you can find out what architecture your phone is using.

The way to find out requires a terminal app on the phone, and the README names one, termius, and gives the command to run, which is `adb shell uname -m`.

The reply tells you the architecture the Linux kernel in your Android OS is running, and the README is careful to note that it does so in Linux terminology rather than Android ABI names. Then comes the mapping:

A aarch64 reply is the arm64-v8a ABI. An armv7l reply is the armeabi-v7a ABI. An x86_64 reply is the x86_64 ABI. And an i386 or i686 reply is Android's x86 ABI.

The table exists because the naming is genuinely confusing. The APK filename uses the Android ABI names, and the command that tells you which one you need prints the Linux names, and the two vocabularies only loosely correspond. Getting aarch64 confused with arm64-v8a is a common enough mistake that having the mapping written down is worth the trouble.

Maintenance signals, and what this repository is for

The repository is not archived and the last push was on 2026-09-25, so the artefact hosting is still being maintained. The releases are recent as well, with the most recent tags in August and September 2026.

There is a small wrinkle in the metadata worth mentioning, because it reflects the nature of the repository. The primary language is recorded as unknown and the licence as unknown, which is what a repository of binary release artefacts looks like to an automated classifier. There is no LICENSE file in the top level listing, only README.md and test.md.

So the licence question is not settled by the repository itself. The Joplin project is open source, and the builds here are built from that source, so the question of what terms the artefacts are under follows the application rather than this repository. If the exact terms matter to you, the project's own repositories are where to check.

What this repository gives you is a way to obtain a specific Android build of a note taking application, with enough guidance to pick the right file. The Play Store page is the ordinary route and is preferable for most people, since the store handles updates. The APK route is for the cases the store does not cover: a build ahead of the store, a build for an architecture the store does not serve, or a device where the Play Services are missing.

Editorial conclusion

Use joplin-android as the download point when you need a Joplin APK that is not in the Play Store, and read the architecture guidance before you pick a file, because the prefixed builds are per ABI and the universal one is larger. Do not treat this repository as a place to look for the code, since the source lives in a separate repository, and check whether the tag you want is marked as latest, because the README asks you to assume most releases are pre-release builds.

Frequently asked questions

Official sources

1. Issues
2. laurent22/joplin-android on GitHub
3. Project website
4. README
5. Releases