Blokada 6 for Android: what the official repo actually contains
The official repo for Blokada apps.
At a glance
- What is it?
- Blokada's official repository ships the Blokada 6 Android app, a subscription ad blocker that filters DNS in the cloud rather than on the device. The free Blokada 5 lives elsewhere and works differently, which is the first thing to get straight.
- Who is it for?
- Adopt Blokada 6 only if you accept a paid subscription and cloud-side DNS filtering, and you are building or testing the Android app from the Makefile targets rather than installing an APK from this repository. Do not adopt it if you need a free, fully on-device blocker: the README points that use case at Blokada 5, which the file describes as a separate, independently developed edition.
- Can I use it commercially?
- Yes, with conditions. MPL-2.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Dart, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Blokada 6 solves, and who the repository is written for
Blokada is a mobile ad blocker and privacy app. The repository's README opens on Blokada 6 for Android and states plainly that this edition requires a subscription to run. The older Blokada 5 does on-device adblocking instead of cloud adblocking, needs no subscription, and according to the README is entirely free to run. That single paragraph is the most important thing on the page: the project name covers two products with different economics and different filtering locations, and the README says both editions are developed independently.
The audience for this repository is therefore narrower than the audience for the product. Someone who wants to block ads on a phone should read the website and the store listing, not the source tree. Someone who wants to build, sign, translate or test the Android app is in the right place. The top-level layout confirms that: android/, ios/, common/, automation/, deps/, scripts/ and metadata/ sit alongside a Makefile and a BUILDING.md, and the README sends developers to BUILDING.md and to a developers-only forum for build questions. There is no user installation guide in the README at all.
How the app is put together: Flutter, two flavors, one Makefile
The primary language is Dart, and the repository has both android/ and ios/ directories plus a common/ module, which is the shape of a Flutter application with platform folders. The Makefile makes the flavor split explicit. It defines FLAVOR := family and carries targets for both families of build: build-android-family and build-android-six, build-ios-family and build-ios-six, with debug and quick variants of each. So the same codebase produces the free-family and six editions, and the difference is a build flavor rather than a branch.
Build orchestration runs through make rather than through the platform tools directly. The default goal is build. There are targets for versioning (version, version-clean) that call scripts/version.py and patch android/app/build.gradle or ios/IOS.xcodeproj/project.pbxproj, a translate target that shells out to scripts/sync-translations.sh, and install targets (install-family, install-six and their debug forms) that presumably push a build to a connected device. Publishing is wired to fastlane through targets such as publish-android, promote-android, publish-ios-testflight and fastlane-match. The CI surface is visible too: ci-build-android-family, ci-build-android-six, ci-build-ios-family, ci-build-ios-six.
One comment in the Makefile is worth quoting because it explains a design constraint rather than a command: release-pipeline invariants that cannot be recovered from once broken, where store codes only ever go up and the offset is applied exactly once. That is why a separate test-scripts target exists and why it needs only bash, git and python3 so pull-request CI can run it off the self-hosted pool. The repository treats its version numbering as a correctness problem, not a formatting detail.
Installing it: there is no APK here, only a build path
The README does not give installation steps for end users. It gives a store link for trying Blokada 6 and points build questions at BUILDING.md. If you want the app on a phone, the README's answer is the Google Play listing; if you want to compile it, the answer is BUILDING.md plus the Makefile. The commands below are the ones the Makefile defines, and they are the closest thing to an install procedure the repository states.
Start by listing what the default goal actually does, then run the test suite the way the Makefile intends, which regenerates the common module first:
make -n build
make testThe test target runs make -C common/ pub gen-android runner and then make -C common/ test, so the common module is generated before it is tested. For a faster loop that skips generation, the Makefile offers test-local.
To produce and push a debug build of one edition, use the flavor-specific install target:
make install-six-debug
make install-family-debuginstall-six-debug and install-family-debug are separate targets, which matches the two flavors. If you only want the artifact without touching a device, build-android-six-debug and build-android-family-debug are the corresponding build targets. The Makefile also defines quick variants for each, and a plain uninstall target.
Version bumps go through the version script rather than by hand, because the script edits the Gradle and Xcode project files:
make version
make version-cleanExpect the script to modify android/app/build.gradle and ios/IOS.xcodeproj/project.pbxproj. Because the Makefile comment warns that store codes only ever go up and the offset is applied exactly once, treat version-clean and the test-scripts target as part of the release procedure rather than optional cleanup.
The subscription split is the real limitation
The clearest constraint is not technical. Blokada 6 requires a subscription, and the README states that in the first paragraph. Anyone who arrives at this repository expecting a free ad blocker has the wrong repository, and the README says so directly: Blokada 5 does on-device adblocking, does not require a subscription, and is entirely free to run. Because the two editions are developed independently, a fix or a feature in one does not imply anything about the other.
The second constraint is that cloud adblocking moves the filtering decision off the device. The README uses cloud adblocking as the defining difference from Blokada 5's on-device approach, and it does not describe what that means for latency, for which data leaves the phone, or for behaviour when the service is unreachable. Those are the questions a privacy-conscious reader will ask first, and the README is silent on all of them. That silence is not evidence of a problem, but it is a gap you should close from the website and the FAQ before adopting, not from the source tree.
The third constraint is release cadence as visible in the repository. The recent releases listed are android.v5.23.2.1 from 2023-05-25, android.v5.23.1.10 from 2023-02-27, and an archive bundle from 2023-02-08. Those are Blokada 5 Android builds, not Blokada 6, so the release list does not tell you anything about the edition the README leads with. The last push to the repository was on 2026-09-23, so work is happening, but the published release tags do not track it. If you need a versioned Blokada 6 artifact, this repository's release page is not where you will find it.
Where it sits next to on-device blockers and DNS-level tools
The obvious alternative is the one the README itself names: Blokada 5. The difference is the filtering location. Blokada 5 filters on the device and is free; Blokada 6 filters in the cloud and is subscription-based. That is not a feature-tier difference, it is an architectural one, and it changes what you can reason about. With on-device filtering, the blocklist and the matching logic are on hardware you control, and the app's behaviour does not depend on a remote service being up. With cloud filtering, the matching happens elsewhere, which is why the subscription exists, and the README does not document what the device sends or what happens when the remote side is unavailable.
Beyond Blokada's own two editions, the wider category splits the same way. DNS-level blocking tools configure a resolver and leave the filtering to that resolver, which is conceptually close to Blokada 6's cloud model but usually without a client app managing it. Hosts-file and local-proxy blockers sit on the device, closer to Blokada 5. The choice between them is really a choice about where your DNS queries are answered, and Blokada 6's README takes a position on that question by making cloud filtering the headline difference. If you are evaluating this repository, decide that question before you evaluate the code.
Maintenance, licensing and what an upgrade actually costs
The repository is not archived, and its last push was on 2026-09-23. That is a recent change, so the tree is being touched. The release tags, however, are older, and the newest of them is a Blokada 5 Android build from 2023-05-25. Read together, those facts say the repository is active but its release page is not a reliable signal for the edition the README describes. Anyone tracking Blokada 6 versions should watch the store listing, not the tags.
Upgrade cost is concentrated in the version and release tooling. The Makefile routes version changes through scripts/version.py, which rewrites android/app/build.gradle and ios/IOS.xcodeproj/project.pbxproj, and it carries a comment that store codes only ever go up and the offset is applied exactly once. That means a mistake in versioning is not something you can quietly undo on the next release, which is why test-scripts exists as a separate target with a minimal dependency set. If you fork this repository, the version script and its tests are the part you should read before you touch anything else.
The licence is MPL-2.0, a file-level copyleft licence. Modified files stay under MPL-2.0 when redistributed, while separate files can carry other terms. That is a statement about the licence text, not legal advice; if you plan to ship a modified build, have someone qualified read the LICENSE file and the notices that ship with it.
Editorial conclusion
Adopt Blokada 6 only if you accept a paid subscription and cloud-side DNS filtering, and you are building or testing the Android app from the Makefile targets rather than installing an APK from this repository. Do not adopt it if you need a free, fully on-device blocker: the README points that use case at Blokada 5, which the file describes as a separate, independently developed edition. If you want the free path, verify on blokada.org which edition is current for your platform before downloading anything, because the README warns that mirror sites copy the product and only blokada.org is official. If you want to build, read BUILDING.md first and confirm the Flutter toolchain the Makefile targets expect.
Frequently asked questions
Is Blokada completely free?
It depends on the edition. The README states that Blokada 6 requires a subscription to run, while Blokada 5 does on-device adblocking, does not require a subscription, and is entirely free to run.
How do I install Blokada on Android?
The README points users at the Google Play listing rather than giving install steps, and it warns that blokada.org is the only official site. Building from source is a separate path covered by BUILDING.md and the Makefile.
What is Blokada?
The README describes it as an open source mobile ad blocker and privacy app, with Blokada 6 filtering in the cloud and Blokada 5 filtering on the device.
How do I use Blokada 5?
The README says Blokada 5 does on-device adblocking, does not require a subscription, and is entirely free to run, and that both editions are developed independently. It does not give usage steps, and points to the main GitHub page for source code.
How do I set up Blokada?
The README does not document setup for end users. It links a Getting Started page at go.blokada.org/faq and a Google Play listing for trying Blokada 6, while build questions go to BUILDING.md and a developers-only forum.
Is it safe to use Blokada?
The README does not discuss safety directly. It does warn that malware sites copy the product from time to time and states that blokada.org is the only official website, with every other copy or mirror unrelated to the project.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/blokadaorg-blokada)