AFWall+ puts its donation section before its own description, and admits system apps can bypass its rules

The default branch is named beta

The repository's default branch is called beta, not master or main, and the documentation is written around that. The link to release notes points at a changelog file on the beta branch, so the notes you read for a published release live on the branch named for unreleased work. The releases themselves are conventional: v4.1.0 on 2026-08-06, v4.0.3 on 2026-03-01 and v4.0.2 on 2026-02-23, three patch-level or minor steps across about six months. The root also carries a Changelog.md, so the file exists in two places in spirit, once on the branch you land on and once in the tree. A badge near the top points at a workflow specifically for building binaries, which is the part of this project that is not an ordinary Gradle application, as the development section later shows.

The donation section comes before the software is described

The second section of the README is about paying for the project, and it arrives before the section that explains what the software does. It states that AFWall+ is free and open source and developed by volunteers, then lists what a donation is for, and then gives five ways to pay: a PayPal button, an unlocker key for extra features on Google Play, an Amazon gift card by email marked as not preferred, a Bitcoin address and an Ethereum address. The unlocker is worth reading twice. It is sold as an in-app purchase on the Play Store, and separately the text says that after donating you should send your receipt to an address at a domain named portgenix to receive an unlocker, allowing one to two days for a reply. The free application is therefore the front end to a paid key delivered by email.

The limitations section names the hole in its own model

Five limits are stated plainly, and one of them is structural rather than incidental. Root access is required, with no root meaning no functionality. It is not an antivirus, because it does not scan files for malware. It is not an ad blocker, because it blocks network access rather than ads inside connections you have already allowed. Some VPN apps may interfere with the firewall rules. And the fifth is the one to weigh: system-level apps, meaning some system processes, may bypass the rules if they themselves have root access. Since the firewall works by intercepting traffic at the kernel level with iptables rules, a process that can write its own rules is outside the model, which is why the app is a control for ordinary applications rather than a boundary against a compromised system.

Four root methods, two of them qualified

The root requirement is spelled out as a list of the methods the documentation says are supported, and two carry a judgement. Magisk is marked recommended. LineageOS built-in su is listed without a qualifier. SuperSU is marked legacy. KingRoot is marked not recommended. That list is the practical compatibility statement for the whole application, since nothing works without one of them, and it is separate from the Android version range, which is stated as 5.0 at API level 21 through 14 and above, with older Android releases covered by legacy versions of the app named in the same paragraph.

The two custom rule examples use different chains

Advanced users can write their own rules, and the two examples given do not target the same chain. The first, which allows a specific address range, appends to a chain named for the WiFi interface. The second, which blocks a TCP port, appends to the base chain instead. Since the whole design of the application is per-app and per-network-type filtering, a rule written against the base chain is not being filtered the way the first one is, and a reader copying the second example into a per-app situation would get different behaviour from the first. The targets also differ, one accepting and one rejecting. Elsewhere in the same section, packet logging is described as using a kernel logging interface rather than iptables, so a single document mixes two different kernel interfaces for the same page of settings.

Compatibility runs from Android 2.x to 14 and above

The compatibility line is short and the parenthetical matters: Android 5.0 at API level 21 through 14 and above, with 14 and above annotated as the actively maintained part. Underneath, one line covers everything older, naming the version of the app that supported Android 4.x and the version that supported Android 2.x. So the current application starts at a platform from several years ago, while the project has shipped versions reaching back to the earliest Android releases, and the gap between those two lines is not explained anywhere in the document. Four architectures are listed, ARM, ARM64, x86 and x86_64, and storage is given as about 15 megabytes for the application plus about 5 megabytes for binaries, which is the first hint that native code is bundled rather than compiled on the device.

Native binaries are built by a separate script and workflow

The build prerequisites are an Android SDK at API level 21 or newer, Java 17 or newer, Git, and the Android NDK, listed as needed for the native binaries. The quick build is three commands:

git clone https://github.com/ukanth/afwall.git
cd afwall
./gradlew clean assembleDebug

Those commands produce an application, not the binaries, which is why the NDK and the extra 5 megabytes both exist. The root of the repository carries an NDK makefile, a build-binaries shell script, an external directory for third-party sources, a binaries directory, a playstore directory and a scripts directory, and the badge at the top of the README points at a workflow whose name is building those binaries. So the shipped artifact is assembled from two build paths, a Gradle build for the app and a separate native build whose output is bundled into it.

Six network types and four rule profiles

The filtering dimensions are wider than the WiFi and mobile data pair most firewalls offer. Mobile data is listed with roaming detection across 3G, 4G and 5G, and WiFi is broken down into home, work and public hotspots. Then come VPN, described as all types and providers, tethering across WiFi hotspot, USB and Bluetooth, Tor with onion routing support, and LAN for local network access. On top of those, the app keeps named profiles, with four described by their intent rather than their rules: home is relaxed for a trusted network, work is restrictive for a corporate one, public is maximum security, and travel is balanced. Automation comes through a Tasker and Locale integration, alongside multi-user support, password protection, and boot protection that applies the rules before apps start.

Editorial conclusion

AFWall+ fits an owner of a rooted device who wants per-app network control and is willing to accept the cost of running an app with root privileges. Its limitations section is the most useful part of the documentation: it needs root, it does not scan for malware, it does not remove ads inside allowed connections, some VPN apps interfere with its rules, and system processes that themselves hold root can get past them. Three things to check before you rely on it. Rule application happens through iptables chains, so a custom rule written against the wrong chain does nothing, and the two examples in the README use different chains. The unlocker for the extra features is delivered by email after a donation rather than in the store, which is worth knowing before you install. And the default branch is called beta, with release notes on that branch rather than on a stable one.

Frequently asked questions

Official sources

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