AdGuard for Android: a network-level ad blocker that is not open source

The repository is a tracker, not a codebase

The first thing to settle is what this repository is not. Its description reads "Open bug tracker for Android version of AdGuard", and the top level of the tree holds only `.github/` and `README.md`. There is no build system, no manifest, no source tree and no Gradle wrapper. The project states this directly: "AdGuard for Android is not an open source project. We use GitHub as an open bug tracker for users to see what developers are working on."

That single sentence decides the adoption question for most engineering teams before any feature is discussed. You cannot read the filter logic, you cannot build the app from source, you cannot vendor a fix, and you cannot audit which hosts are contacted at startup. What you get instead is visibility into intent: open bug counts, resolved bug counts, and a feature request queue sorted by reactions.

The AdGuard organisation does publish separate open source work, and the README links to that listing. The point is narrower and more awkward. The product you install on a phone is the part that stays closed, so a review of AdGuard for Android is a review of a distributed binary, not of a source artifact.

Two interception modes and what each one can and cannot reach

The mechanism the README describes is network interception, and it offers two modes: VPN or HTTP proxy. In VPN mode the app holds the device's local VPN slot, routes traffic through itself, and matches requests against filter lists before they leave. In HTTP proxy mode traffic is routed through a proxy configuration instead.

The distinction is the whole engineering story. VPN mode is the mode that can act on apps which never open an HTTP proxy, because every packet is captured regardless of which library or WebView produced it. That is why the README can claim blocking "in apps and browsers even without ROOT privileges". The cost is that only one application can hold a local VPN slot at a time, so this app cannot coexist with a corporate VPN client or a traffic inspection tool on the same device.

HTTP proxy mode avoids that collision, but it only reaches traffic that honours a proxy setting, which is a much narrower slice of a modern Android device. Neither mode can remove an advertisement already baked into a video file or an image baked into an app bundle, because at that point the request has already succeeded.

Custom DNS with DNSCrypt, and the failure modes DNS filtering introduces

The app also allows custom DNS settings, with DNSCrypt support stated in the README. Upstream DNS resolution and request filtering are therefore separate layers you can adjust independently, which matters when you need to keep resolution working while tuning what gets blocked.

This layer is also where breakage shows up first. Encrypted DNS in particular interacts badly with captive portal detection: a network that expects a plaintext lookup to a specific resolver can treat the device as offline. None of these behaviours are documented in this repository, so they cannot be checked here and should be expected to be discovered by trial on a given app and network.

Getting the app: stores, sideloading and what you cannot read first

The README gives no installation command, no package name, no `adb` line and no build step, because there is nothing here to build. It points you at https://adguard.com/adguard-android/overview.html to get the app, and it lists three additional Android storefronts besides the usual route: AppGallery at https://agrd.io/github_huawei_adblocker, the Mi App Mall at https://agrd.io/github_xiaomi_adblocker, and Galaxy Store at https://agrd.io/github_samsung_adblocker.

Those links matter more than they look. Each vendor store is listed because the standard store distribution does not serve every vendor's build, which is itself an argument that shipping a network interceptor across fragmented Android builds is not a solved problem.

A first real use is therefore not a command you run. It is: fetch the build, grant the local VPN permission, pick a filter list, then open the apps that matter to you and watch whether logins and push notifications still arrive. The repository contains no script for that check.

A licence check is the documented outbound request

The README's privacy note is unusually specific for a product that is not open source: "AdGuard sends only necessary, limited information, e.g. information required for a license check", with the full text at https://adguard.com/privacy/android.html.

Read narrowly, that sentence defines the app as one that contacts AdGuard's servers, which is an operational fact a network engineer filtering its own egress should plan for. Because the binary is closed, that claim is not verifiable from this repository. The privacy policy page is the only source, and it is maintained by the vendor rather than tracked by the issue tracker.

Release cadence and the boundary of what the tracker tells you

The repository is archived=no and the last push was on 2026-10-09. Recent releases are v4.14.2 on 2026-09-25, v4.14.1 on 2026-09-15, and v4.14 on 2026-09-09, so patch-level work is landing on a monthly cadence.

That cadence measures tracker activity, not shipped code correctness, because the commits behind those pushes are issue triage and repository housekeeping rather than the app itself. The README's own contribution structure reinforces that: the paths into the project are reporting an issue, translating AdGuard, other contribution options, and becoming a Beta tester. None of them are pull requests against a source tree, because there is no source tree.

Where the difference from alternatives actually lies

Compare this with a network-level blocker you can build yourself from open source. The approach difference is not about filter list quality; it is about who holds the code and who absorbs breakage. A self-hosted resolver with filtering enabled, or a self-hosted proxy, gives you configuration in version control, upgrade on your schedule, and the ability to read what each rule does. AdGuard for Android gives you a maintained UI, per-app controls, and notification-based app management, at the cost of an unreadable filter and an unverifiable outbound request.

For a personal phone, that trade is often worth it. For a test fleet or a regulated environment, the closed binary is usually disqualifying on its own.

Editorial conclusion

AdGuard for Android is a reasonable choice for an individual who wants ads and trackers blocked system-wide on a personal device without root and will accept a closed binary and a licence check that the project says sends limited information. It is the wrong tool for an engineer auditing what runs on a device, for a managed work profile where a VPN slot is already taken, or for anyone who needs the filtering logic under version control. Before adopting, open https://adguard.com/adguard-android/overview.html, install the build for your device, and confirm that your apps still authenticate after DNS and request interception are enabled, because the repository contains no test you can run to predict that outcome.

Frequently asked questions

Official sources

1. AdguardTeam/AdguardForAndroid on GitHub
2. Issues
3. Project website
4. README
5. Releases