TrackerControl watches tracker DNS, not what travels behind it

Detection matches DNS names, so SSL payloads stay closed

TrackerControl takes its traffic view from Android's own VPN service and works on DNS queries rather than on decrypted content. Nothing in the pipeline opens an SSL connection, which the README names as the reason the app runs on an unrooted phone and why the only thing recorded is metadata about network communications. Detection is therefore a lookup: a query name goes against the lists, and the match decides both whether the request counts as tracking and whether it is blocked.

That design fixes a blind spot of its own. If a tracker hides inside an app's encrypted channel, or resolves a hostname that no list covers, there is nothing to match on, because the payload carrying the evidence was never opened. Traffic analysis still beats library analysis for the reason the README states plainly: tracker libraries sitting in app code may never be activated at runtime, while a network hit is actual evidence that data was shared.

SNI reading waits for Research mode because it would leak the address

Server Name Indication would give TrackerControl hostnames hidden behind shared CDN infrastructure, but extracting it means connecting to the tracker server. The README keeps that off by default and ties it to Research mode instead, on the grounds that the connection would otherwise hand over the device's IP address to the very company being measured.

The mitigation is narrower than it sounds. The SNI value is read locally out of traffic TrackerControl is already inspecting, with no separate connection opened to fetch it. If remote routing over WireGuard is also on, the outbound connection to the tracker travels the tunnel, so the tracker sees the VPN provider's address instead of the real one. With remote routing off, which is the default position, that ordering argument does not apply.

Minimal spares browsers, Standard and Strict do not

Fresh installs land on the Minimal blocking mode, and Minimal is the only mode that auto-excludes known incompatible apps such as browsers from the VPN. Standard and Strict both switch that behaviour off. The safety net that keeps a browser working on day one disappears the moment you move to a mode offering per-app and per-tracker controls, which is the usual reason to move there. Anyone changing modes should expect breakage in the apps Minimal was quietly sparing.

Minimal also draws its tracker lists from DuckDuckGo alone, and it is the only one of the three without granular per-tracker control, so it is also the mode where a single tracker cannot be let through while the rest stay blocked. Essential services are allowed in both Minimal and Standard and only get blocked in Strict.

Strict also blocks Content and mixed shared IPs

Standard and Strict run on the same tracker sources, given in the mode table as X-Ray, Disconnect and DDG, and both expose granular per-tracker control. What separates them is collateral. Standard lets the Content category through to reduce breakage, which the README offers as the knob to turn when apps misbehave. Strict blocks Content, and it also blocks ambiguous shared IP cases where a tracker hostname and a non-tracker hostname resolve to the same address.

That second rule works on resolution results rather than on names, which makes it a blunt instrument. A tracker and a legitimate host landing on one IP is ordinary on shared infrastructure, and Strict settles the tie by refusing both. The blast radius is wider than the name-based lists imply, and the README does not document a way to see which hosts were dropped for sharing an address.

The Play Store build ships blocking in one mode only

Two distributions are published, and the comparison table between them differs in a single row. Tracker Analysis, Traffic Log, Secure DNS over HTTPS and remote VPN routing are marked present in both. Blocking is present in both too, but the Play Store build is limited to Minimal mode while the F-Droid and GitHub builds carry all three. Someone who installs from the Play Store, finds no per-tracker control and concludes the feature is missing has diagnosed a build difference, not a defect.

The identifiers diverge alongside the features. The store listing is net.kollnig.missioncontrol.play, the F-Droid entry appends an .fdroid suffix, and the IzzyOnDroid listing uses the bare net.kollnig.missioncontrol, which is not the app's name either. Installing the GitHub APK next to either store build therefore produces two separate installations under two identifiers, not one app in two places.

Research mode logs domains and stops blocking

Research mode writes contacted domains straight to the console and, in the same pass, disables blocking. The stated purpose is research studies that instrument apps using an additional computer, which is a fair reason to want raw output on standard output. The cost is that the app stops blocking for as long as the mode stays on, and the documentation gives no way to tell from outside that it has been left that way.

The same trade runs through system app analysis. It is disabled by default because it can lead to unexpected behaviour, and it is reached through Settings, then Advanced Options, then Manage system apps. Google Maps, YouTube and Google Play Services are the interesting targets there, since other apps piggyback on them for tracking, but attributing that activity to a specific app is hard. The one place the write-up breaks down is the traffic log paragraph, which ends on the word The with no sentence after it.

Attribution is the weak point, not the matching

The advice for cleaner results is not a setting: uninstall as many apps as possible first. Once Google Maps, YouTube or Google Play Services sit inside the analysis, activity triggered by some other app is hard to pin on the app being watched. The same feature that exposes hidden trackers also produces results that resist being pinned to a cause, and no mode setting repairs that.

It also collides with the blocklist story. The overview says detection combines the Disconnect blocklist, the DuckDuckGo Tracker Radar list for mobile apps and an in-house list built from analysing around two million apps. The mode table, three headings later, names X-Ray, Disconnect and DDG as what Standard and Strict use. The in-house list is missing from that row, and nothing says which of the two descriptions is authoritative for a given mode.

An Android app shipped beside a website, a paper and a Rust bridge

The top level of the repository holds more than the application. A Doxyfile sits beside documentation.html and an index.html carrying a CNAME and a .nojekyll file, so the project website is generated from the same tree as the code. paper.md, paper.bib and CITATION.cff sit alongside them, the filing a project publishing on its own method would keep. A rust-toolchain.toml and a wgbridge-rs/ directory add a Rust component to a repository whose primary language is Java, and that directory name points at the WireGuard bridge behind remote routing.

Two root entries say more about how the work is done. HOTPATH_BUG_AUDIT.md is tracked as a document in the repository root, and AGENTS.md, CLAUDE.md and an agents/ directory are committed next to the Gradle build, those being the names agent tooling conventionally uses. None of it changes what the app blocks, but the tree reads as a working area rather than a clean source tree, so anyone auditing the detection logic has to look past the app directory.

Editorial conclusion

TrackerControl is worth installing for anyone who wants to see which companies their apps talk to, and the DNS-first approach is the reason it runs on an unrooted phone. Read the mode table before leaving Minimal, because the auto-exclusion that keeps browsers alive exists only in that default. Treat the output as directional: attribution across piggybacking apps is the weak point, the app's own disclaimer says results may be inaccurate, and the traffic log paragraph ends on the word The with nothing after it. The last push was on 2026-09-24 and the newest release tag is 2026080501, dated 2026-08-05.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. TrackerControl/tracker-control-android on GitHub