The GitHub repository is a mirror, and the tracker is on GitLab

You are looking at a mirror, and the issue tracker is somewhere else

The repository description says it is mirrored from a GitLab project, and every pointer in the README agrees. The homepage field is the GitLab URL. The issues line at the top of the file is a GitLab issues link, not a GitHub one. The contributors line points at a GitLab profile. The default branch is named the older convention rather than the current one. Even the CI configuration and its directory are GitLab's, which means the pipeline that builds this project runs on the other host entirely. The only GitHub-specific thing in the file is the repository itself. This matters more than a naming detail, because it determines where you should report a bug. Opening an issue here would put it in a mirror that appears to have no issue tracker attached, so it would go nowhere. The README is explicit that issues go to GitLab, and it is the one instruction in the file that is not optional. Anyone arriving from a search result rather than from the project's own site will land in the wrong place, which is probably why the warning is written as a bold label rather than a sentence.

The Play Store build cannot do the app's main job on recent Android

There is a note attached to the feature list, and it is the most practically important line in the README. For Android 12 and later, the Google Play version does not have permission to access all files, and the instruction is to use another version, specifically F-Droid or the direct APK. Read that against the feature list. The app's headline capabilities are choosing which files in a torrent to download, moving files while downloading, automatically moving completed files to another folder or an external drive, and streaming with sequential downloads. Every one of those needs broad storage access. So the version most people will find first, by searching the Play Store, is a build that cannot perform the features the README advertises. The reason is the Play Store's own permission model, not a choice by the developer, but the effect is that the flagship channel is a reduced product. Six channels are listed in total, and two of them are named here as the ones to prefer.

Six distribution channels, and a certificate fingerprint for the one you build yourself

The badges at the top of the file are a distribution strategy in six parts. There is an entry on a free software repository, an entry on an open APK index, an entry on an APK mirror site, a Play Store listing, a listing on a third-party app store, and a mirror on the author's own domain. For the direct download route the README gives you a SHA-256 fingerprint certificate, formatted as a colon-separated block, and tells you it will let you verify the app. That is the right thing to publish and it is worth using: if you are installing a torrent client from a bare URL, verifying the signature is the only thing standing between you and an arbitrary binary. The distinction matters more here than for most applications, because a torrent client is by design a program that opens network connections to strangers and writes to shared storage. The six-channel approach is also a hedge against any one platform tightening policy, and given the note about the Play Store's permission model, that hedge is doing real work rather than being decoration.

The protocol list is complete enough that most desktop clients would envy it

The feature list includes a line that reads like an inventory of trackerless and NAT-traversal protocols, and it is worth taking at face value. Distributed hash table, peer exchange, protocol encryption, local service discovery, universal plug and play, NAT port mapping, and a micro transport protocol. That is the set of mechanisms a BitTorrent client needs to find peers and open connections without a functioning tracker, which is what you want when the obvious trackers are blocked. Below that there is a proxy option covering both trackers and peers, which is more specific than most clients document, since it distinguishes hiding your requests to the tracker from hiding your connections to peers and those are different privacy properties. There is also IP filtering with two named blocklist formats, both long-standing community blocklists, which means the filtering data can be supplied by the user rather than baked in. And the first line of the list is the surprising one: support for both BitTorrent 2.0 and WebTorrent. The second of those is a browser-oriented protocol, and supporting it in a native Android client is not something you would attempt unless the underlying library made it free.

The engine is a Java binding, which is why the primary language is Java

One line in the feature list names the foundation: the app is based on a Java binding to libtorrent, a specific fork of which is linked. That single fact explains most of what you see in the repository. The language is Java, the build is a Gradle project with a settings file and a properties file, and the licence is version three of the GNU General Public License, which is the licence a Java wrapper inherits from the C++ library it wraps. It also explains the protocol coverage. libtorrent is a mature C++ library, and the binding exposes its full feature set rather than a subset, so protocol support is inherited rather than reimplemented. That is a good trade for a client application. You get two decades of protocol edge cases handled in C++, and you get an Android build without maintaining a native toolchain. The cost is that the binding is now load-bearing: the app cannot be modernised past whatever that library supports, and an upstream change becomes your problem. There is a second developer dependency too, since a Coverity scan badge sits in the header, so static analysis runs as well.

Donations are accepted in eight forms, one of them by post

The donations section is the longest part of this README, and it is worth reading as a document about how an individual funds a project. There are three cryptocurrency addresses, one each for Bitcoin, a dollar-pegged token on one chain, and a privacy-oriented coin whose address runs across three lines because of its length. Then a domestic bank transfer number for a service popular in Russia, a Patreon page, a subscription platform, a recurring-donation service, and finally an offer to buy the developer an Amazon gift card of whatever amount you like, with the amount and a contact address to be typed into the gift card details. That last one is unusual and, in a small way, the most useful entry, because it moves the transaction onto a platform with buyer protection. The section opens by saying development is fully funded by people like you and closes with thanks, and it explicitly offers a contact address for anyone having payment trouble or wanting to donate some other way. A single developer is listed as the developer, and the header also points at a chat and a Telegram channel, so the project is visibly one person with a community around it.

Release signing is set up from a template, and there is no CI on the mirror

Two entries in the tree tell you how releases are actually made. There is a fastlane directory, which is the automated release pipeline, and a file whose name is an example rather than a real key file, sitting next to the build configuration. That pairing is the standard Android release setup: signing material is never committed, an example file documents which fields are needed, and the pipeline reads the real values from somewhere else at build time. It is a sensible arrangement and it is worth naming because a torrent client asking for broad storage access is exactly the kind of application where a hijacked release key would be genuinely damaging. The absence of release notes is more surprising given the same repository has a NEWS file at the root, which suggests release notes are maintained separately from the version history rather than generated from it. And the CI configuration being GitLab's own, combined with the mirror relationship, means there is no pipeline on this host at all: cloning from here gives you code, not a build. The README does not mention the mirror in its build instructions, so a contributor who starts here and expects continuous integration to run will not get it.

Editorial conclusion

LibreTorrent suits an Android user who wants a torrent client with no advertising, no account and a complete protocol stack, and who is comfortable verifying a signature and installing from outside a store. Four things to know before you install. Do not take the Play Store version on Android 12 or later, because the README says it lacks all-files access and the app's main features depend on it. Report problems on GitLab, since this repository is a mirror with no issue tracker of its own. If you install the direct APK, verify the published SHA-256 fingerprint certificate, which is the only check standing between you and an arbitrary binary in an application that connects to strangers by design. And note this is a single-developer project whose only developer is listed by name, so the long-term risk to plan for is one person's availability rather than a licence or a vendor.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. proninyaroslav/libretorrent on GitHub
4. README
5. Releases