Aria2Android: running aria2 as an Android service

A wrapper that puts a download manager on the phone

Aria2Android is an Android application whose stated purpose is narrow: it lets you run aria2 on your device. The project description says it in one line, and the repository exists to make that possible from a phone rather than from a router or a desktop.

aria2 is the piece that matters here. It is a download manager, and it is the sort of thing that is normally installed on a machine rather than on a phone, so having it in the Google Play listing and on F-Droid is the interesting part of the project. The badges in the readme link to both a Play Store listing under the package name com.gianlu.aria2android and an F-Droid entry under the same identifier.

The repository itself is a Java project, and the primary language is recorded as Java. That tells you what the application is written in, and the build is a Gradle project with the usual wrapper files, gradlew and gradlew.bat, a build.gradle at the root, a settings.gradle and a gradle directory holding the wrapper configuration, plus a gradle.properties file.

The last push was on 2026-05-13, and the release history shows v2.6.6 and v2.6.7 on the same day in October 2023 followed by v2.6.8, so the tagged releases are behind the working tree and the project is being touched without cutting a release every time. The topic tags name android, android-service, aria2, aria2-gui and java, which is a fairly precise description of the shape of the thing: an Android service wrapping aria2, with a graphical front end.

Two submodules and a shared utility library

The top level of the repository is where the architecture shows, and there are two entries that stand out.

There is a CommonUtils directory, and the setup section says this project uses devgianlu/CommonUtils and asks you to follow the link to set up your environment properly. The presence of that instruction in a short readme is a strong hint about the workflow, because it means the project cannot be built from a fresh clone without first arranging that dependency in the way the author expects. It is a shared library from the same author rather than a general purpose one, so what it provides is whatever several of the author's projects need, and the app-specific code sits elsewhere.

There is also an aria2lib directory, and a .gitmodules file at the root. The submodule file is what makes that meaningful: aria2lib is not vendored into the repository as ordinary files, it is a reference to another repository that is checked out during the build. That is the usual arrangement when the upstream project is large and has its own release cadence, and it means the aria2 sources the app builds against are a version you do not choose here, you inherit from the submodule pointer.

The app/ directory holds the Android application module itself, and Graphics/ holds the artwork, including the logo that appears at the top of the readme as a horizontal image. The CHANGELOG.md at the root is the version history, and the LICENSE file carries the GPL-3.0 terms that the repository is recorded as using.

The .github/ directory holds the workflows, and the readme shows an Android CI badge pointing at a workflow named Android CI on the master branch. So the build is verified automatically on every push rather than only when the author remembers to run it.

Distributed through two stores, and translated through Crowdin

Two things in the badge row say more about how the project is run than the code layout does.

The first is distribution. The application is on Google Play and on F-Droid, and the F-Droid presence matters more than it usually would for a mobile app. F-Droid builds from source and publishes what it builds, so a listing there is a statement that the build is reproducible from the repository without proprietary tooling and without the developer's involvement. For an application that embeds a large third party downloader, that is the arrangement that lets somebody check what is actually in the package.

The second is translation. The badge row includes a Crowdin badge linking to the Aria2Android project on Crowdin, and the repository has a crowdin.yml file at the root, which is the configuration that tells the platform which source strings to pull and where to put the translated ones. Crowdin is a translation management service, and using it with a configuration file in the repository is the pattern where translators work in the web interface and the translated strings come back into the build automatically.

The consequence is that the readme is in English while the application is not English-only, and that adding a language does not require a developer. It also means the source strings are in the source tree in a form the platform can read, which is a small but real design decision about where the user-facing text lives.

The remaining badges are ordinary project hygiene: a Codacy badge reporting a code quality grade for the repository, and a WakaTime time tracker badge, which together suggest a project with automated quality measurement and with commit activity tracked over time.

The setup instruction is short, and it is the whole getting-started guide

The readme is genuinely brief. It has a heading with the logo image, a row of badges, a one-line description, the two store badges, and then a setup section that consists of a single sentence pointing at another repository.

That is worth reading as a choice rather than an omission. The project is not trying to be a tutorial for aria2, and it is not trying to explain the Android service architecture. It assumes you know what aria2 is, and it assumes you have a build environment set up the way the author's other projects expect, which is what the CommonUtils instruction is really telling you.

There is a separate section for the logo, which says the logo has been renewed by a contributor with a link to the issue where that happened, and that is the entire note. It reads like a changelog entry for a design change rather than a section of documentation, which is consistent with a repository where the readme is a pointer to the two things a visitor needs, which are the store listing and the setup step.

If you are evaluating the project, that tells you what to look at instead. The store listing tells you what the application does and how it behaves, the setup repository tells you how to build it, and the repository itself is where you look at the code. The readme is a signpost between those three places rather than a description of the application.

What this project is for, and where it sits

It is worth being explicit about the use case, because the name suggests something narrower than it is.

The point of running aria2 on a phone is that a phone is often the device that has the network you want to use. A phone on a hotel wifi, on a mobile data plan, or tethered to something else can be the fastest link available, and a download manager that runs there turns the phone into a download node rather than a client of one. The topic tags place this in the same family as aria2's usual desktop use, and the android-service tag suggests the download runs as a background service so it survives the screen turning off.

So the value proposition is not that the application reimplements anything. aria2 does the downloading, and the application is the packaging, the configuration surface and the service lifecycle that make it usable on Android. That is a small amount of work in one sense and a large amount of work in another, because the platform fights every part of it: background execution limits, storage permissions, and the fact that the download manager expects a filesystem layout that Android restricts.

What the repository gives you to judge that is the structure. An app module, a bundled aria2 library as a submodule rather than a fork, a shared utility library from the same author, a Gradle build, continuous integration on push, and translations managed outside the codebase. There is no Python, no shell tooling and no build step for the native library visible from here, which is a good sign: the native side is upstream's problem, and this project is about delivering it on Android.

Two things to check before you rely on it. The tagged releases stop at v2.6.8 from October 2023 while the last push is in May 2026, so the store build and the repository head are not the same thing, and the gap is likely the embedded aria2 version. And the setup depends on another repository, so a fork needs that arrangement reproduced rather than just a clone.

Editorial conclusion

Aria2Android suits someone who wants the phone to do the downloading rather than just request it, since the point of the application is putting a full download manager on a device that has the best available network. It does not suit you as a starting point for your own Android application, because the build is arranged around one author's environment and the shared library has to be set up first. Before you rely on a release, check the version gap, since the newest tag is v2.6.8 from October 2023 while the working tree was pushed in May 2026, which means the embedded aria2 is likely newer than the last tagged build.

Frequently asked questions

Official sources

1. devgianlu/Aria2Android on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases