# ShizuWall blocks apps without a VPN, and in whitelist mode a broadcast reverses meaning

> An Android firewall that works through the platform's per-package networking controls rather than a tunnel, with three ways to obtain the privilege it needs and an ADB broadcast surface for automation. The subtle part is what the state flag means when your policy is a whitelist instead of a blacklist.

**AhmetCanArslan/ShizuWall** — Lightweight, no vpn firewall solution for Android 11+

- Repository: https://github.com/AhmetCanArslan/ShizuWall
- Stars: 2,311 · Forks: 66
- Language: Kotlin
- License: GPL-3.0
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/ahmetcanarslan-shizuwall

## It is the platform's own per-package switch, not a tunnel

The reason this app is not a VPN is stated in the header, and the mechanism is worth reading because it explains everything else.

ShizuWall uses a platform mechanism called Chain 3, described as the connectivity chain, to control per-app networking. The page explains it as an Android platform mechanism that intercepts and controls per-package network access at the system level, which is what allows fine-grained firewall control. The commands it executes through Shizuku or the local daemon are these four:

```bash
# Enable firewall framework
cmd connectivity set-chain3-enabled true

# Block specific app
cmd connectivity set-package-networking-enabled false <package.name>

# Unblock specific app
cmd connectivity set-package-networking-enabled true <package.name>

# Disable firewall framework
cmd connectivity set-chain3-enabled false
```

Two properties follow from reading that. There is no tunnel, no packet interception and no persistent VPN session, which is the stated reason for choosing this approach over the alternative. And the firewall has a global switch separate from the per-app switches, so turning the framework off is a different action from unblocking an app.

That is the whole implementation, and it is worth being clear about what it is not. It does not inspect packets, so it cannot block an app by destination or by protocol, only by package. It does not route traffic anywhere. And it relies on a platform interface that a future Android release could change or remove, which is the standard risk of anything built on an internal command surface.

The stated benefits follow from the same choice: privacy first by design, described as offline first with no analytics, no telemetry and no tracking, and three control surfaces for the same state, a quick settings toggle, an app widget and a floating firewall button.

## Three backends, and each one is a different trust decision

The app needs system level access and offers three ways to get it, and the differences between them matter more than the app's own feature list.

Shizuku is described as a secure API that communicates with system services, requiring the Shizuku application, and the page notes that forks are supported. Shizuku works by running a service that holds shell level privileges, which means its privileges end when the device reboots and you restart it. A Shizuku fork is therefore a third party component holding the same privilege as the official one, and the readme does not take a position on which fork.

Root access is the second option and is described in one line: direct root access, obtained by rooting the device with standard methods. That is the strongest grant and the one with the longest lasting consequences, since a rooted device has no equivalent of the reboot boundary.

The third is a wireless debugging client, named LibADB and also LADB. The description is the interesting part: it uses the phone's built-in wireless debugging feature to act like a computer connected over USB, which lets the app make advanced system changes without a computer, without root, and without an extra application such as Shizuku.

That third option is the one most people will not expect, and it reframes the whole product. Wireless debugging is a platform feature that gives a paired device the same channel ADB uses, so the app is driving its own phone over a debugging connection rather than through a privileged service.

The stated floor is Android 11, and exactly one of the three is required. That is a sensible requirement for an app whose entire value is a system interface, and the fact that it works on a stock device without root is the practical point of the LADB path.

## A broadcast with apps reverses its meaning in whitelist mode

There is an automation surface, and its semantics are the most subtle thing on the page.

The control action is a broadcast, handled by a named receiver component, carrying one required extra and one optional one. The required extra is a boolean state. The optional one is a comma separated list of app keys, and if it is omitted the app uses whatever selection it has already saved. An entry in that list may carry a profile prefix, with an example given for a work profile or clone copy, while a bare package name targets user zero.

The behaviour note is the part to read twice. A broadcast carrying apps keeps the app in sync rather than merely acting: state true selects those apps and turns the firewall on if it was off, while state false unselects them and leaves the firewall on. In whitelist mode the same extra addresses the allow list instead, so the two states are reversed. Without the apps extra, the broadcast is a plain global toggle.

So the same three commands mean different things depending on which policy you are running. Under a blacklist, true adds apps to the blocked set and enables the firewall. Under a whitelist, true adds them to the allowed set. An automation written once and run after you switch modes will do the opposite of what you intended, and nothing in the broadcast will report an error, because from the app's point of view both requests were valid.

If you script this, read the mode before you write the script rather than after.

## Clones mirror rules until you turn on Show other profiles

Android's work profiles, cloned apps and private spaces complicate a per-app rule, and the page describes both the default behaviour and the escape hatch.

Clones are handled automatically unless a setting called Show other profiles is on. With that setting off, a bare package name mirrors its rule to every clone of that app. With it on, each profile is addressed separately, using the numeric prefix in the app key so that one specific copy is targeted rather than all of them.

That is a sensible default with one sharp edge. A rule that means block everywhere becomes a rule that means block only one clone as soon as somebody flips the setting, and a user with several clones may not know which mode their rule is in.

The second broadcast is about new installations, and it exists to solve a limitation rather than to add convenience. The app's own detection relies on the platform's package-added event, and it only receives that for the profile it runs in. So a newly installed app inside a work profile, a clone space or a private space is invisible to it. The page's position is that an automation application that can watch those other profiles reports the install instead, and the broadcast is the interface for that.

That broadcast requires the apps list rather than making it optional, which is the right asymmetry: there is nothing to fall back on when the caller has not said what was installed. An example is given with the user flag set, for the case where the sending automation runs outside the main profile.

Two more details. The receiver is declared in the manifest, so the broadcast works even when the app monitor service is stopped, and that service is only needed for the app's own detection inside its own profile. And the policy applied depends on the active mode: in whitelist mode the new package is blocked immediately, in other modes it is blocked and added to the selected apps only when the auto firewall new apps setting is on. While the firewall is off, no rule is applied at all.

## A separate licence for tracker data

The tree has three documents that describe what this app does with data, and only one of them is the software licence.

There is the main licence file, a privacy policy document, and a third file whose name gives away its subject: a licence for tracker data. That file exists because the app ships or generates a definition of what counts as a tracking application, and a list of named applications is a separate creative work from the code that consumes it.

That is worth pausing on, because the app's headline claim is privacy first, local only, with no analytics, no telemetry and no tracking. Those four words describe the app's own behaviour. Being able to tell a user which installed applications are known trackers is a different capability, and it requires data that someone had to assemble and that carries its own licensing terms.

The split is the right one to make. If the data were bundled under the same licence, redistributing the app would carry an obligation about the list, and a maintainer who wanted to update the list would be constrained by the code's licence. Splitting them means the list can change on its own terms.

It also means a user has two things to evaluate rather than one: the application, and a dataset it consults. The privacy policy is the third document and is the one to read for what leaves the device, which on the project's own account is nothing.

## Eleven readmes, two stores, and a release twelve minutes after the last push

A few final facts that tell you what kind of project this is.

The documentation set is large relative to the code: eleven readme files in the repository, covering English plus Turkish, German, Italian, Portuguese, Czech, Russian, Arabic, Hindi, Chinese and Japanese. The tree also carries a Gradle wrapper for Windows, a tools directory, and a fastlane directory, which is the tooling used to publish to an application store catalogue.

That fastlane directory matters because of the two distribution channels. The app is on both the Play Store under its own package identifier and F-Droid. Those are different provenance for an application whose entire job is to control other applications on your device: a store build has passed a review process, and an F-Droid build is reproducible from source. Having both means a user who cares about provenance can choose, and a user who does not can install whichever is convenient.

The release cadence is visible too. The three most recent releases are 4.6.3 in late August 2026, 4.6.4 in early September, and 4.6.6 on 3 October. The last of those was published twelve minutes after the last commit on the default branch on the same day, which is what a release cut looks like when it is automated. The version sequence skips 4.6.5 in the list visible here, and a version numbered in the fourth decimal place on a firewall app is a project shipping patches often.

The repository carries few open issues and a modest fork count relative to its stars, which fits an application that people install and then leave alone.

## Conclusion

ShizuWall fits someone who wants per-app network control without giving an app a VPN slot, on a device they can grant Shizuku, root or wireless debugging to. Four things to check before you install it. Which backend you will use, because Shizuku, root and wireless debugging are three very different trust decisions, and the readme says forks of Shizuku are supported without saying which one you are trusting. Which mode you run, because the same broadcast means opposite things in blacklist and whitelist mode, and getting that wrong silently inverts your policy. Whether your automation will see installs in other profiles, since the app only detects packages in its own profile and depends on a task automation app to report the rest. And where you install it from, since a Play Store build and an F-Droid build are different provenance for an app whose whole premise is controlling other apps.

## FAQ

### how to use shizuwall

Install it, grant one control backend, and pick a firewall mode. ShizuWall needs Android 11 or higher and exactly one of Shizuku, root access, or the wireless debugging client described as LibADB or LADB. Control comes from a quick settings toggle, an app widget or a floating firewall button, and you can also drive it from scripts with an adb broadcast.

### what does shizuwall do

It blocks or allows network access per application using Android's connectivity chain 3 platform controls, executed through Shizuku or a local daemon. Because it uses the platform's per-package networking switch rather than a VPN, there is no packet interception and no persistent tunnel.

### Is ShizuWall safe to use without root?

The page describes two ways to avoid root. Shizuku runs a service that communicates with system services and needs restarting after a reboot, and forks are supported. The other route uses the phone's built-in wireless debugging feature so the app can act like a computer connected by cable. The stated requirement is Android 11 or higher and one of those backends, the local daemon, or root.

### Can ShizuWall control apps in other user profiles?

Not by itself. The app only sees package installs for the profile it runs in, so an automation application that can watch other profiles has to report them through the app's broadcast interface, passing the apps list with a numeric profile prefix when the install is in a work profile or clone space. The receiver works even when the app monitor service is stopped.

### Where can I install ShizuWall from?

From the Play Store under the package com.arslan.shizuwall, or from F-Droid. Both channels are linked from the repository, and the repository also carries a separate licence file for tracker data alongside the main licence and a privacy policy, since the application ships or consults a definition of which applications are trackers.

## Sources

- [AhmetCanArslan/ShizuWall on GitHub](https://github.com/AhmetCanArslan/ShizuWall)
- [Issues](https://github.com/AhmetCanArslan/ShizuWall/issues)
- [License: GPL-3.0](https://github.com/AhmetCanArslan/ShizuWall/blob/main/LICENSE)
- [README](https://github.com/AhmetCanArslan/ShizuWall/blob/main/README.md)
- [Releases](https://github.com/AhmetCanArslan/ShizuWall/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ahmetcanarslan-shizuwall