super-video-downloader: an Android downloader with a browser attached

What the application is, and the disclaimer above it

The project is an Android video and audio downloader with a browser, a player and custom downloaders, written in Kotlin, and the first section of the readme is a disclaimer.

The project was created for research and educational purposes to explore the downloading of a wide variety of video formats and stream types, and the developer does not take any responsibility for illegal actions performed by users of the application.

That disclaimer is the conventional one for a tool of this kind, and it is worth reading alongside the rest of the readme rather than skipping it. What the tool does is not exotic: it finds the media address behind a page and saves it. What is exotic is the range of containers and stream types it copes with, and that is the research part.

The recommended way to get the application is from F-Droid, and the readme makes a point about how it is published there. It is published as a reproducible build, and F-Droid verifies that the source code matches both their own binary and the package in the repository's releases. That is a stronger provenance claim than most applications make, and it is verifiable by anyone, which means you can check that the build you install is the build in the repository.

The application is also on Google Play, and the developer asks for donations to continue the work, with a table listing a Bitcoin address.

Where the media comes from, and in what containers

The site support is the first feature, and it is inherited rather than invented.

You can download videos from YouTube, Facebook, Twitter, Instagram, Dailymotion, Vimeo and over a thousand other sites, with the list pointing at the support list of the tool the project is built on. The project is inspired by an earlier Android application built on the same foundation, and the acknowledgements name three contributors who worked on it.

The second feature is the one that makes it more than a wrapper. It intercepts and downloads complex stream types like HLS, with the M3U8 extension, and DASH, with the MPD extension, in addition to standard MP4 video streams.

Those two formats are the reason a naive downloader fails on most modern sites. A progressive MP4 can be fetched with a plain HTTP request. An HLS stream is a playlist of segment URLs that the player assembles as it plays, and a DASH stream is a manifest of media segments described in XML. To save one of those you have to parse the manifest, resolve the segment URLs, and concatenate them, and then handle the case where the segments are encrypted or where the manifest is a live playlist that never ends.

The third feature is the live stream downloader, which captures and saves live video and live audio, a radio broadcast for instance, as they happen. That is the hardest case of the three, because there is no end to the stream, so the downloader has to decide when to stop and make sure what it wrote is playable.

A browser, an ad blocker and a proxy stack

The third group of features is what turns the application from a downloader into a small platform.

There is a full-featured browser built in, to make finding content easy, with support for history, bookmarks and cookies. The ad blocker is described as high-performance and is implemented as an integrated Rust-based engine. The networking features are proxy chaining, routing traffic through multiple proxies over HTTP and SOCKS for enhanced privacy, and encrypted DNS with DNS-over-HTTPS and DNS-over-TLS, supporting standard and encrypted sdns URLs.

Embedding a browser is the decision with the biggest consequences, and it is a good one to reason about. The alternative is that the user opens a browser, finds the page, copies the address, pastes it into the app, and the app downloads it. That is workable, and it is what most desktop download managers expect. The embedded browser removes the copy and paste, and in exchange the application now contains a full web engine, which is a large attack surface that fetches hostile content on your behalf.

The same argument applies to the ad blocker, and the Rust choice for it is a performance one. Blocking is a hot path, it runs on every request the embedded browser makes, and the rest of the application is already a mix of Kotlin and Go. The readme lists the networking stack as OkHttp on the Kotlin side with a Go library for the proxy component, and the ad blocker as a Rust crate, so this is a polyglot application with three toolchains.

The download manager is the part that ties it together. It runs the download tasks in the background, and the integrated player handles the offline playback, so the whole path from finding a stream to watching it later is inside one application.

The stack, and why three languages

The readme has a section listing the major technologies, and it is the clearest statement of what the project is.

The language is Kotlin first. The architecture is MVVM with ViewModel and LiveData, with the repository pattern. The user interface is Android Views with data binding, not Compose, which tells you the project has been around long enough that the older view system made sense. Dependency injection is Dagger 2. Concurrency uses both coroutines and RxJava, which is a sign of a codebase that has absorbed both idioms over its life. The database is Room. Networking is OkHttp with a Go library for the proxy support. And the ad blocker is the Rust engine.

Three languages in one application is expensive, and the readme does not pretend otherwise, because the build instructions list the toolchain for each of them: a JDK, the Android SDK and NDK, Go, Rust, and C and C++ build tools.

The reason each one is there is a reasonable one. Kotlin is the only sensible choice for the Android application layer. Go is a good fit for a proxy component, because the network stack libraries for it are excellent. Rust is a good fit for a hot path that parses and matches many rules, and it is also what the ad blocking engine ecosystem is written in. The cost is that a contributor has to install three toolchains, and that the continuous integration has to build all three, which the build commands in the readme reflect with separate targets for the Go libraries and the Rust ad blocker.

Building it, which needs a lot of toolchains

The build section is a compact set of copy and paste commands, and the prerequisites list is where the cost shows.

You need JDK 21, the Android SDK and NDK with release 29 recommended, Go 1.27.0 for the networking components, Rust installed through the usual script on Linux and macOS or through the Windows installer, and C and C++ build tools. The C and C++ requirement is the one people are surprised by on an Android project, and it is there for the native dependencies in the ad blocker.

The first build step is initialising the git submodules, which the readme marks as required after the first clone:

git submodule update --init --recursive

Then the Gradle tasks do the work. A debug build on macOS or Linux is:

./gradlew :app:assembleDebug

with a matching release task, and a separate Windows invocation using the batch wrapper. There are also targets that build only the Go dependencies or only the Rust ad blocker, which is the practical way to iterate when you are working on one of the three languages rather than the whole application.

There is also a documented escape hatch for the Go toolchain. If the go binary is not on the path, you can override the detected one with an environment variable, or pass it as a Gradle property, and the readme gives both forms.

export GO_EXECUTABLE=/opt/homebrew/bin/go

The repository carries a fastlane directory, which is how the release builds and the store listings are produced, and the continuous integration configuration is in both a GitHub workflows directory and a GitLab pipeline file, so the project builds on two services.

The project state, and how it is funded

The licence is GPL 3, the default branch is master, and the release history shows a steady stream of patch versions: 0.8.25.6 in July 2026, 0.8.25.7 in August and 0.8.25.9 later in the same month, with the last push on 2026-09-17 and the repository not archived.

Translations are handled through a Weblate instance, and the readme asks for help there rather than for pull requests with translated strings, which is the arrangement that works when a translation platform is available.

The funding section is worth noting because it is a project maintained by one developer with an explicit request. If you want new features, bug fixes and updates, the readme says, you could support the project by donating. The table lists a Bitcoin address.

So the shape of the project is clear. A single developer, an app with an unusually broad feature set for what it is, a large contributor credit list, a reproducible build story, and a donation link. For somebody deciding whether to install it, the F-Droid route is the one to take, because the reproducibility claim means the binary is checkable, and the donation request is the reason to expect continued maintenance rather than an abandoned repository.

Editorial conclusion

Super Video Downloader suits a person who wants to keep a copy of media they can lawfully access, in a container they can play later and without a network, and who wants that to work on an Android phone rather than a desktop. It is a poor fit if you need a command line tool on a server, and a poor fit if you do not want an application with a browser, a proxy stack and a Rust ad blocker inside it, since the security surface of the whole thing is the browser. Before you install, read the disclaimer in the readme about the intended research and educational purpose, and use the F-Droid build so the binary is verified against the source.

Frequently asked questions

Official sources

1. alexch33/super-video-downloader on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases