Skip to content

Wize AdBlock VPN Engineering

Cold-Start and DNS Lifecycle Bugs in a VPN-Style Ad Blocker

An Android ad blocker VPN lives or dies on its lifecycle. Six real Wize AdBlock VPN commits for cold-start, teardown, and platform-modernization fixes.

Cold-Start and DNS Lifecycle Bugs in a VPN-Style Ad Blocker preview

Written by the Fulldive product engineering team, based on direct inspection of the repositories listed below.

An Android ad blocker VPN that works perfectly in the demo and flakes out at cold start is indistinguishable, to the user, from one that is broken. That is the unglamorous truth behind this category of apps. This post walks through six commits from Wize AdBlock VPN (repo fulldiveVR/FulldiveExtension.AdShield, package com.fulldive.extension.adshield.dnschanger) that each fixed a specific lifecycle or platform issue, and explains why this kind of work is most of the job.

If you want the conceptual “what is a DNS ad blocker” answer first, start with DNS ad blocking vs VPN ad blocking on Android. This post is for the engineering story.

The lifecycle in one diagram

A local DNS sinkhole wrapped in Android’s VpnService has at least these transitions:

  1. App launch (cold start) → resolver initialization → VPN consent → service up.
  2. Service running → DNS queries in → answers (sinkhole or forwarded) out.
  3. Network change (Wi-Fi to cellular, or vice versa) → re-establish resolver.
  4. User-initiated disconnect → teardown of the tun interface → icon off.
  5. OS-initiated kill (Doze, low memory, another VPN taking over) → graceful exit or stale state.

Every one of those arrows has a bug class. The six commits below each patched one.

1. Cold-start DNS loading

commit 6640e596 `` addresses a case where DNS resolver setup was not complete by the time the first query arrived after service start. The user sees the VPN key icon appear, opens a browser, and the first page load bypasses the blocker. It is a narrow window, milliseconds wide, and it is also the window a user actually tests the app in.

The fix is ordering: ensure the resolver is ready before the service advertises itself as up. This is cheap once you notice it and miserable to notice.

2. Skip VPN network in DNS query

commit 32aead39 `` ensures outgoing DNS queries that the blocker itself makes (to look up upstream resolvers, for example) do not loop back through its own VPN interface. Without this, you can get a feedback loop: the blocker tries to resolve its upstream, Android routes that query through the VPN it just established, which is the blocker itself, which asks the upstream, and so on.

In practice, this manifests as slow or stuck DNS resolution, not as a visible crash. Users report it as “ad blocker makes internet slow,” which is not wrong.

3. Graceful VPN teardown

commit 886a3f2c `` fixes the service stopping cleanly. On the Android VpnService API, teardown involves closing file descriptors, clearing the tun interface, and letting the status bar VPN icon go away. A botched teardown leaves a phantom icon, confuses the connection state machine, and can prevent the service from restarting without an app kill.

“The VPN key icon is still there after I turned the app off” is the bug report for this class of issue, and it is a trust-eroding bug even though no traffic is actually being routed.

4. DNS wizard lifecycle and flicker

commit 7033779b `` addresses the onboarding DNS wizard. Wizards that span several screens and drive a state machine are a classic place for state bugs: rotate the device, a step transitions twice. Background the app mid-wizard, the state restores to the wrong step. Flicker is the visual symptom; the underlying issue is that the wizard’s Android lifecycle was not aligned with the view state.

A DNS wizard for a filtering app is not decoration. It is where the user grants VpnService consent and selects a resolver. Flicker here reads as “the app does not know what it is doing,” which is worse than the literal flicker.

5. 16 KB library alignment

commit ead5d3b1 `` is not a lifecycle fix. It is a Google Play platform requirement. Android’s 2025 changes require native libraries in shipped apps to be 16 KB page aligned (Android Developers: 16 KB page size). Apps that miss this start failing Play compatibility checks on newer hardware.

For a DNS/VPN app built on native code paths, this is a mandatory modernization step. It is also the kind of work that produces zero user-facing change if done correctly and a “this app cannot be installed” error if skipped.

6. SDK 36 and version 1.0.17

commit b8315876 targets SDK 36, the Google Play target API level requirement, and `commit ` `7a6c12d9` tags version 1.0.17. These two together are the “we did the modernization work and shipped a release” artifact. SDK 36 means going through every deprecation and behavior change between your previous target and 36, testing, and fixing what breaks. A version tag after that work is the evidence that the test pass cleared.

Why this stacks up to “real engineering”

If you lined up just the user-visible features of Wize AdBlock VPN across 2025 and 2026, you could summarize them in one paragraph. If you line up the commits, the picture is different. Cold start, teardown, wizard state, native library alignment, SDK target, resolver loops — these are six places the app could have silently regressed into “does not actually block anything” or “cannot install on new devices.” The reason any of them did not is that someone wrote those fixes.

This is the case for not treating ad blockers as commodity code. Any single DNS-filtering library can be dropped into a project. Keeping it running on Android, across years of OS and Play Store changes, is the actual product.

What this does not fix

In the spirit of the limitations we attach to every Wize AdBlock VPN post:

  • Reliability fixes do not make the app block more ads. The blocklist and the model of DNS-level filtering set that ceiling.
  • Reliability fixes do not add anonymity. The app still does not hide your IP.
  • Reliability fixes do not replace a full traffic-privacy VPN.
  • Reliability fixes do not protect against domains not on the blocklist.

The difference between a working lifecycle and a broken one is the difference between a usable filter and a useless one, not the difference between filtering and full privacy.

Where to go next

Sources

Last updated: 2026-04-16. Commit hashes and version numbers are drawn from Fulldive repositories inspected on 2026-04-13.