DEV Community

Cover image for Android: End Data Tracking Now
Raho
Raho

Posted on

Android: End Data Tracking Now

#android #privacy #network #tutorial

Preface

Why protecting the flow of your data matters more than ever

Today more than 63 % of all web traffic originates from smartphones, and a single device now handles roughly 133 exabytes of data per quarter (a 13‑fold increase since 2017). Every DNS query, every HTTP request, and every packet that leaves your phone traverses networks owned by mobile carriers, public Wi‑Fi hotspots, or even state‑run DPI (Deep Packet Inspection) systems. Without end‑to‑end encryption, those intermediaries can read, log, or even manipulate the very content you think is private. In 2023 alone, 3 205 data‑breach incidents—a 72 % jump over the previous year—exposed ≈ 19.8 billion records, underscoring how vulnerable unprotected traffic truly is.

At the same time, the market for personal data is booming. Global data‑broker revenues reached US $374 billion in 2023 and are projected to surpass US $670 billion by 2032 (CAGR ≈ 8 %). Roughly 70 % of Android apps embed at least one third-party tracker, 15% have ≥ 5 trackers, and more than 48% transmit data to Google’s advertising and analytics services. A study of 10 000 apps published in May 2023 found that 17% of Android apps falsely claim they do not collect personal data, yet they silently exfiltrate it over the network. In short, even if you install a “privacy‑focused” ROM, the applications you run can still ship your fingerprints to countless unseen parties. Moreover, 25 % of U.S. adults have suffered a data compromise while using public Wi‑Fi (cafés, airports, hotels), and more than 30 % of Android users leave “Secure DNS” disabled, meaning their browsers fall back to the carrier‑provided resolver instead of an encrypted one.

The stack—a hardened Android ROM, a VPN client with a kill‑switch, system‑wide DNS‑over‑TLS (Private DNS) pointing to DNS provider, and a hardened browser—addresses precisely the network‑level exposures described above. The ROM removes pre‑installed Google Services, eliminating the default telemetry pipeline. The VPN encrypts every IP packet from your device to the VPN gateway, and the kill‑switch guarantees that a sudden drop never falls back to an unencrypted carrier link. DNS‑over‑TLS ensures that neither your carrier nor a rogue hotspot can see which domains you resolve, while NextDNS’s blocklists strip out known ad‑ and tracker‑domains before the request ever leaves your device. Together, these layers guarantee double encryption (DoT → VPN) and full visibility control over DNS, effectively neutralizing ISP/DPI snooping, public‑Wi‑Fi eavesdropping, and fallback leaks.

What the stack does not protect is the content that an app decides to send once the encrypted tunnel is established. If an application embeds a third‑party SDK that harvests location, contacts, or device identifiers, that data will still travel through the tunnel—now shielded from the network but still reachable by the remote service. Therefore, achieving true privacy also requires disciplined app selection and awareness of the permissions you grant.

Having laid out the scale of the threat and explained exactly which attack surfaces this configuration mitigates, let’s move on to the practical steps. Below you’ll find a step‑by‑step guide—starting with flashing a hardened ROM and ending with configuring NextDNS and Proton VPN—that turns the theory into a usable, privacy‑first Android experience.

Operating system – start with a hardened Android

  • Preferred: GrapheneOS on a Pixel device.
  • Alternatives: LineageOS or any other privacy‑focused custom ROM where Google Play Services can be removed and which gives you full control over networking.

GrapheneOS gives you a clean base, per‑app sandboxing and verified boot, which is essential for a privacy‑first stack. Installing this firmware takes no more than 10-15 minutes and does not require any technical knowledge or tools. Simply connect your phone to a second device via USB-C and follow the official guide.

This is the first and most important step in ensuring near-complete privacy. Even if you're not considering flashing your phone, the stack still can give you some capabilities to keep most of your data secured, so I invite you to read to the end or skip to the Conclusion to form your own opinions.

Install a VPN client from a trusted source

  • Grab the Proton VPN (simple option) or other VPN provider's APK (e.g., IVPN, Mullvad; paid options) from F‑Droid or the official website/GitHub repository. The Proton's free tier is sufficient for the workflow.
  • Enable the Kill‑switch. Open Settings → Network & internet → VPN → Proton VPN (appears after first connection) → Turn on Always on VPN and Block connections without VPN.

Choose a privacy‑focused browser

  • Vanadium (the Chromium‑based, hardened browser shipped with GrapheneOS) is ideal.
  • Alternatives that respect DoT and have strong anti‑tracking capabilities: LibreWolf (FOSS, community-driven, no tracking), Brave (gathers some metadata, but gives strong anonymization capabilities) and others.
  • Use DuckDuckGo or alternative privacy-focused search engines.

In order to prevent the browser from using its own DNS to bypass the configured DoT (explained further below), it is necessary to go to the browser settings and disable the “Secure DNS” option. Furthermore, disable “Safe Browsing”. Adjust the “WebRTC IP handling policy” to Disable non-proxied UDP. It is important to note that the security of the traffic will be ensured by the DNS resolver that will be configured subsequently.

Although DuckDuckGo is listed as a recommended search engine, the DDG browser is not recommended for use due to the lack of a customizable WebRTC IP handling policy, which means that personal data may leak even when the entire stack is configured.

Configure NextDNS (browser‑only version)

  • Create a profile on the NextDNS dashboard.
  • Add blocklists you need (here is my blocklist set): NextDNS Ads & Trackers Blocklist, AdGuard DNS filter, OISD, HaGeZi – Multi ULTIMATE, 1Hosts (Xtra), notracking, Goodbye Ads.
  • Security tab: Enable Threat Intelligence Feeds, AI‑Driven Threat Detection, Google Safe Browsing (here we ENABLE the option, as it does not transfer data to Google itself), Cryptojacking Protection, DNS Rebinding Protection, IDN Homograph Attacks Protection, Typosquatting Protection, Domain Generation Algorithms (DGAs) Protection.
  • Privacy tab: Enable Block Disguised Third‑Party Trackers.
  • Settings tab: Adjust logs retention to 1 hour, storage location to Switzerland. Turn on: Anonymized EDNS Client Subnet, Cache Boost, CNAME Flattening, Bypass Age Verification, Web3 (optional, but useful for modern sites).

All of these options are available in the web UI; you do not need the native NextDNS client.

Activate Android Private DNS (DoT)

  • Open Settings → Network & internet → Private DNS.
  • Choose “Private DNS provider hostname” and enter your profile’s endpoint: [profile‑id].dns.nextdns.io.

This forces all system DNS queries to be sent over TLS to NextDNS through configured VPN tunnel.

Crucially, Proton VPN does not replace your DNS when you already have a Private DNS (DoT) configuration – the DNS packets remain encrypted end‑to‑end to the DNS provider, and the VPN only wraps the whole IP payload. See Proton’s own note that “DNS queries are routed through the VPN tunnel to be resolved on our servers”, but this only applies when you let the app supply its DNS; with Private DNS the DNS stays with your chosen resolver. The NextDNS endpoints are routed automatically when you switch the VPN server. Because the DNS traffic is already wrapped in TLS, the VPN tunnel later adds another layer of encryption (AES + TLS) but does not alter the DNS destination.

How the pieces work together

Connecting to a regular WiFi or cellular network

  1. Device obtains an IP address via DHCP/PPP from the AP.
  2. All outbound packets (including the TLS‑wrapped DoT queries which are first encrypted when the resolver opens a TLS session on port 853) are handed to the VPN client.
  3. The VPN client sees the outgoing IP packet, wraps the whole thing in its own AES + TLS tunnel, and forwards it to the selected Proton VPN server.
  4. Inside that tunnel the packet still contains the DoT‑encrypted DNS request destined for [profile-id].dns.nextdns.io.
  5. The VPN server forwards it to the NextDNS edge node; NextDNS decrypts the DoT layer, looks up the domain using the blocklists/security settings you configured, and returns the answer (still inside the DoT envelope).
  6. The answer follows the reverse path: NextDNS → Proton VPN server → VPN tunnel → your phone → the application (browser, app, etc.).

The client’s MAC address changes each time it reconnects if the "Per‑connection Randomized MAC" feature is enabled (Android 12 and later).

Result: Every DNS lookup and every HTTP(S) request is double‑encrypted (DoT + VPN) and the only visible metadata which is available to the WiFi provider or the carrier is “The client with this MAC address used that much traffic volume at this time from that VPN IP”; it does not see the domain names you are looking up, nor the content of the HTTP(S) requests, because those are hidden beneath both encryption layers.

Using your second device as a Hotspot

  1. The client device receives a local IP from your Hotspot’s DHCP.
  2. Its encrypted traffic reaches the second device’s WiFi interface, is routed through its network, and then (once it arrives back on the Pixel) follows the client’s routing table, which includes the active VPN tunnel, VPN and DNS servers.

The Hotspot:

  • Does not know the traffic route
  • Simply transmits the encrypted packet
  • Only sees the MAC address of the connected device, volume and timing characteristics of the packets
  • Cannot analyze the content
  • Being only a transport channel

Thus the Hotspot does not become a weak point; it merely acts as a bridge for the already‑protected traffic. But the second device still gets the same amount of metadata as in the WiFi and cellular network options. That means Google Services, stock OS developers and network provider of second device can obtain it, if not removed.

Optional extra hardening

  • Disable “Allow background data” for any non‑essential app: Prevents silent data bursts that could bypass the VPN kill‑switch. Open Settings → Apps → Select app → WiFi data usage / App battery usage → Background restriction.
  • Avoid installing unnecessary apps.
  • Whenever possible, use Progressive Web Apps (PWAs) or home‑screen shortcuts to web services.
  • Only install a native app when a PWA truly cannot replace it (e.g., a hardware‑specific utility).

Fewer apps mean fewer surface‑area attacks and fewer chances for accidental DNS leaks.

Conclusion

Fast, low‑latency connectivity
By chaining a system‑wide DNS‑over‑TLS resolver (NextDNS) with a reliable VPN (Proton VPN) and a privacy‑focused browser (Vanadium or Brave), every packet that leaves your phone is encrypted twice – first at the DNS layer (DoT) and then inside the VPN tunnel (AES + TLS). The result is a responsive connection that works on public Wi‑Fi, home routers, cellular network and even when you share the mobile data via a Hotspot.

Why a separate DNS service matters
Built‑in “secure DNS” features in browsers/VPNs are convenient, but they do not give you full control. Using an external DNS provider with DoT brings several decisive benefits:

  • Full log ownership – you decide how long logs are retained, where they are stored, or disable logging altogether.
  • Granular filtering – you can add aggressive blocklists that browsers usually avoid for compatibility, tightening protection against ads, trackers, malware, and phishing.
  • Isolation of failure – keeping DNS separate means a compromise of the browser’s DNS client cannot affect the system‑wide resolver; the two layers are independent.
  • System‑level protection – DoT runs before any app can see the query, guaranteeing that no raw DNS data leaks to applications on the device.
  • Shield against fallback leaks – on stock Android devices the OS may fall back to Google’s DNS or the carrier’s resolver when a TLS handshake fails, and some Google services can issue their own DNS queries that bypass the system resolver. An independent DoT resolver prevents these fallbacks, ensuring every query stays encrypted end‑to‑end.

Practical implications for non‑rooted devices
Even without flashing a custom ROM, you can enable DoT in Android’s network settings and pair it with a VPN that offers a kill‑switch. This simple configuration already blocks the majority of DNS‑related leaks that would otherwise expose your browsing habits to Google, your ISP, or any on‑path observer. The only remaining exposure is the possibility of a fallback to an unencrypted resolver when the TLS handshake to the DoT server fails. Using a dedicated DNS provider greatly reduces the likelihood of such a fallback, but it does not eliminate it entirely—if the secure connection cannot be established, the system may revert to the default DNS server.

Overall security posture
The combined stack—system‑level DoT, Proton VPN with kill‑switch, and a hardened browser—delivers near‑complete anonymity for everyday web surfing. Most users employ these components only partially, leaving gaps where DNS or traffic can be observed. By integrating them as described, you achieve a cohesive, high‑performance privacy solution using freely available, easily configurable tools.

Feel free to ask questions or share your own tweaks!

Top comments (0)