DEV Community: llama

Android: End Data Tracking Now

llama — Thu, 02 Oct 2025 03:19:47 +0000

"I should not be reliant upon Google's algorithm to tell me what I should pay attention to, because they're programming you… And they can change that algorithm at any point and program you in a different way, and they have in the past, and they will continue to do so.”
– Jack Dorsey (former CEO of Twitter)

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.

What the Stack Offers in Terms of Privacy Protection

The stack—a hardened Android ROM, a VPN client with a kill‑switch, a GPS spoofing tool, 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. The GPS spoofing tool prevents your real location from being disclosed by other applications. 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 sufficient 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 DNS-over-TLS—that turns the theory into a usable, privacy‑first Android experience.

OPERATING SYSTEM

Preferred: GrapheneOS on a Pixel device.
Alternatives: CalyxOS (the relevant paragraph is must-read) 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 Pixel to a second device via USB-C and follow the official guide.

Although the proposed firmwares are the most advanced options available to the average user, there are several important points to consider. We have no available information about who are current directors and sponsors of GrapheneOS, apart from the company's co-founder Daniel Micay, who announced in 2023 that he would resign as lead developer and a director of the GrapheneOS Foundation. However, as of September 2024, he remains listed as one, contrary to his earlier statement. There are also no independent audits of the codebase, despite the fact that the project is completely open source. We are aware of a split in the company when James Donaldson (CEO of the parent company called CopperheadOS) attempted to seize the project's infrastructure, steal donations, and take control of the project. CopperheadOS is currently a closed source and is now primarily targeted at enterprise and partner deployments.

As for CalyxOS, the project is primarily supported by The Calyx Institute (a 501(c)3 non-profit organization based in New York). Among the sponsors are names such as Jack Dorsey (former CEO of Twitter), DuckDuckGo, Internews, Wau Holland Foundation, Ford Foundation, and NLnet Foundation. Key figures include Nicholas Merrill (former CEO) and Chirayu Desai (former CTO). The Seedvault project (a backup component) has been partially audited in the past, but a full comprehensive security audit of the entire codebase has not been performed. As of August 1, 2025, the organization is in a 4-6 month hiatus, so users are advised to be cautious and consider alternative privacy-focused mobile operating systems during this transition period. The interim head of CalyxOS is Ellen McDermott, about whom there is no information at all.

Considering all of the above, this is the first and most important step in ensuring near-complete privacy. I don't say “near-complete” for no reason. In the digital world, you have to choose from what is available. However, this is only an illusion of choice. If the above information makes you doubt, but you want “complete” privacy at all costs, throw away your phone right now.

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.

VPN CLIENT

I won't dwell on this section, as most people are already familiar with the basic functions of a VPN. I just want to clarify that you can use paid plans and services to enable Split-tunneling for installed applications, which can increase your privacy.

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.

GPS SPOOFING AND LOCATION PRIVACY

GPS spoofing is a technique that deliberately provides false geographic coordinates to trick devices or applications into believing you are at a different location than your actual physical position. Without proper GPS spoofing configuration, other apps can indeed gather your real location from the GPS module even when a VPN is active. VPNs only mask IP address and are incapable to override GPS hardware and block native location services.

Setting Up the GPS Spoofing Tool

Fake Traveler is a GPS spoofing tool available on F-Droid that allows you to mock your device's location. It enables users to select a specific location on a map to fake their GPS coordinates and movements. The app doesn't require root access.

Currently, Fake Traveler does not allow you to mock your location in the background when the app is closed. Therefore, depending on the situation, this steps can be useful, but stay optional.

Install Fake Traveler from F-Droid or official GitHub repository.
Enable Developer options. Go to Settings → About phone and tap the Build number seven times until you see a message.
Select Fake Traveler as the mock location app. Open Settings → System → Developer options → Select mock location app → Fake Traveler.
Give the app required permissions. Go to Settings → Apps → Fake Traveler → Permissions → Enable Location and Network.
Set up Fake Traveler preferences. If you want a static location set “Mock movement?” to 0 in both inputs. In case of faking it you should set it around 10-50 and 10-20. First number controls movement scale, second number adds randomness/accuracy variation.
Go back to the map and choose preferred location by typing specific coordinates or pressing, then tap Apply.

Adjusting Location Parameters

To protect your privacy, adjust the system's location settings and limit specific app settings that are set by default during installation.

Disable apps you don't want having control over device's Wi-Fi module. Go to Settings → Apps → Special apps access → Wi-Fi control.
Restrict permissions to Nearby devices. Open Settings → Security & privacy → Privacy controls → Permission manager → Nearby devices.
Disable Wi-Fi and Bluetooth scanning. Go to Settings → Security & privacy → Privacy controls → Location access → Location services. These two settings need to be disabled to ensure the spoofing tool functions correctly.

PRIVACY‑FOCUSED BROWSER

Vanadium is ideal. It's the Chromium‑based, hardened browser shipped with GrapheneOS.
Brave is a good alternative. The app gathers some metadata, but gives strong anonymization and anti‑tracking capabilities.
Use Brave Search or DuckDuckGo as a privacy-focused search engine. Brave Search is superior to DuckDuckGo because it offers a truly independent search index, powered by its own Web Discovery Project.

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 Secure DNS option. Furthermore, disable Safe Browsing and adjust the WebRTC IP handling policy to Disable non-proxied UDP. Set the strict requirement for using HTTPS connections only. Go to the Site settings and Block JavaScript JIT (V8 JIT). 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.

DNS PROVIDER

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.

Setting Up the External DNS Client

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 uses threat intelligence from Google to inform its filtering without directly exposing user queries or personal information), 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).

DNS-OVER-TLS

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.

THE ENTIRE WORKFLOW

Connecting to a Regular Wi-Fi or a Cellular Network

Device obtains an IP address via DHCP/PPP from the AP.
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.
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.
Inside that tunnel the packet still contains the DoT‑encrypted DNS request destined for [profile-id].dns.nextdns.io.
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).
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.

Result: Every DNS lookup and every HTTP(S) request is double‑encrypted (DoT + VPN) and the only visible metadata which is available to the Wi-Fi 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

The client device receives a local IP from your hotspot’s DHCP.
Its encrypted traffic reaches the second device’s Wi-Fi 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 second device:

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.

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 → Wi-Fi 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 with a reliable VPN and a privacy‑focused browser, every packet that leaves your phone is encrypted twice – first at the DoT layer and then inside the VPN tunnel. 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.

Practical implications for devices with stock OS
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—hardened ROM, system‑level DoT, VPN with kill‑switch, and a hardened browser—delivers near‑complete anonymity for everyday web surfing while GPS spoofing tool prevents location data leaks on OS level. 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!

Privacy‑Focused Web Surfing & App Traffic: Setting Up a Fast, Low‑Latency Android Stack

llama — Wed, 01 Oct 2025 13:24:05 +0000

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.

This is the first and most important step in ensuring almost complete privacy. Even if you're not considering flashing your phone, 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 option) from F‑Droid or the official web-site/GitHub repository (the Proton VPN'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: Brave, LibreWolf and others. But some of them still can gather some of your metadata.
Use DuckDuckGo or alternative privacy-focused search engines.

By default the browser use the system DNS if DoT is configured – it will automatically inherit the Private DNS configuration (more info about DoT provided below).

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, 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 (EU‑friendly jurisdiction). 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 (including those generated by apps that do not honor the browser’s DNS settings) to be sent over TLS directly 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 (WiFi or Hotspot)

Connecting to a regular WiFi network (home/public)

Device obtains an IP address via DHCP from the AP.
All outbound packets (including the TLS‑wrapped DoT queries) are handed to the VPN client.
The VPN encrypts the entire IP packet and sends it to the selected VPN server.
Inside that tunnel sits the DoT‑encrypted DNS request destined for [profile-id].dns.nextdns.io.
The VPN server forwards the packet 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).
The answer travels back through the same path: NextDNS → VPN server → VPN tunnel → your phone → browser.

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 is “the client with this MAC address used that much traffic volume at this time from that VPN-IP”.

Using your second phone as a Hotspot

The client device (e.g., Pixel) receives a local IP from your Hotspot’s DHCP (second device).
Its encrypted traffic reaches the Hotspot’s WiFi interface, is routed through second device’s network, and then (once it arrives back on the Pixel) follows the client’s routing table, which includes the active VPN tunnel.
Because the VPN is active on the client device, all traffic from the Hotspot—including the client’s DNS queries—is forced through the same VPN tunnel and the same DoT‑to‑NextDNS chain.
The second device’s MAC address stays constant, while the client’s MAC address changes each time it reconnects if the "Per‑connection Randomized MAC" feature is enabled (Android 12 and later). No DNS or payload data is exposed beyond the fact that a device is connected and uses VPN.

The second phone:

Does not know the traffic route
Simply transmits the encrypted packet
Only sees the 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 network option. That means Google Services, OS creators and mobile 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

Following these steps gives you a fast, low‑latency connection while keeping DNS and payload fully encrypted, and it works equally well on public WiFi, home routers, or when you share your connection from other devices via Hotspot.

I believe that this configuration and use of components is the best solution for everyday web surfing. Unlike those who use only a privacy-focused browser, only a VPN service, or even a private browser with a VPN service, this stack provides almost complete anonymity for your online activities using free and easily configurable tools.

It is not limited to use on custom firmware. Even if you don't want to flash your phone, setting up DoT and a VPN is a simple and affordable solution to prevent your personal data from being leaked to third parties.

Feel free to ask questions or share your own tweaks!

DEV Community: llama

Android: End Data Tracking Now

PREFACE

Why Protecting the Flow of Your Data Matters More Than Ever

What the Stack Offers in Terms of Privacy Protection

OPERATING SYSTEM

VPN CLIENT

GPS SPOOFING AND LOCATION PRIVACY

Setting Up the GPS Spoofing Tool

Adjusting Location Parameters

PRIVACY‑FOCUSED BROWSER

DNS PROVIDER

Why a Separate DNS Service Matters

Setting Up the External DNS Client

DNS-OVER-TLS

THE ENTIRE WORKFLOW

Connecting to a Regular Wi-Fi or a Cellular Network

Using Your Second Device as a Hotspot

EXTRA HARDENING

CONCLUSION

Privacy‑Focused Web Surfing & App Traffic: Setting Up a Fast, Low‑Latency Android Stack

Operating system – start with a hardened Android

Install a VPN client from a trusted source

Choose a privacy‑focused browser

Configure NextDNS (browser‑only version)

Activate Android Private DNS (DoT)

How the pieces work together (WiFi or Hotspot)

Connecting to a regular WiFi network (home/public)

Using your second phone as a Hotspot

Optional extra hardening

Conclusion

Activate Android Private DNS (DoT)