Short answer: Android 17 can make it significantly harder for a Wi‑Fi operator, ISP, or on-path snooper to see the exact domain name an app is connecting to—but only when the app's networking stack and the destination server both support Encrypted Client Hello (ECH).
It is an important privacy improvement, but it is not a VPN and it does not make browsing anonymous. The network can still see connection metadata such as destination IP addresses, timing, and traffic volume. And Android's own documentation makes an important limitation explicit: ECH is active only when the app's networking library has integrated it and the remote server supports it.
Feature check — September 1, 2026: Android 17 reached stable release on June 16. Google highlighted its new ECH support on August 27. For apps targeting Android 17 / API 37 or higher, Android enables ECH for TLS connections when the networking library and remote server support the protocol.
Why HTTPS did not completely hide which site you were visiting
HTTPS already encrypts the useful contents of a modern web connection: page data, passwords, messages, URL paths, form submissions, and other application traffic are protected inside TLS.
But historically, two pieces of metadata could still reveal the destination before that encrypted conversation was fully established:
- DNS: the device asks how to reach a domain such as
example.com. - SNI: during the TLS handshake, the client tells a server which hostname it wants so the server can select the correct site and certificate.
Android's Private DNS feature protects the DNS lookup when Private DNS is being used. Google is unusually clear about the boundary: Private DNS secures DNS questions and answers only; it does not protect the rest of the connection.
ECH tackles the second leak.
The Internet Engineering Task Force standardized ECH in RFC 9849 in March 2026. ECH encrypts the sensitive portion of TLS's ClientHello, including the Server Name Indication (SNI) that can otherwise expose the hostname.
That closes a long-standing gap between “the page contents are encrypted” and “the network can still tell which domain I opened.”
HTTPS vs Private DNS vs ECH vs a VPN
These technologies solve different parts of the privacy problem.
| Protection | What it mainly hides from the local network | What the local network can still observe | Main dependency |
|---|---|---|---|
| HTTPS only | Page contents, messages, passwords, URL paths | DNS lookups may reveal domains; classic SNI may reveal hostname; destination IP and traffic patterns remain visible | Site supports HTTPS |
| Private DNS | DNS questions and answers when Private DNS is active | TLS hostname can still leak without ECH; destination IP and traffic patterns remain visible | Private DNS availability/configuration |
| ECH + Private DNS | Two major hostname leaks: DNS queries and TLS SNI, for supported connections | Destination IP, timing, volume, and other network metadata | App/network library + server + ECH configuration |
| VPN | The local Wi‑Fi generally sees an encrypted tunnel to the VPN rather than each destination connection | It can still see that a VPN is in use, the VPN endpoint, timing, and traffic volume | VPN provider, client, routing, and configuration |
The key takeaway is that ECH improves metadata privacy inside ordinary HTTPS. It does not replace every reason someone might use a VPN.
A VPN changes who can observe the network path: the local Wi‑Fi operator sees the VPN connection, while trust shifts toward the VPN provider. ECH is different. It tries to reveal less hostname information to intermediaries without requiring all traffic to be routed through a separate provider.
What Android 17 actually changes
Android 17 adds platform APIs for ECH and a new domainEncryption setting in Android's Network Security Configuration.
For apps that target Android 17 / API level 37 or higher, Google's current behavior-change documentation says ECH is used for TLS connections when both of these conditions are met:
- the networking library used by the app has integrated Android's ECH support;
- the remote server supports ECH.
If ECH cannot be negotiated, Android supports ECH GREASE, which sends randomized ECH-like data so network observers cannot simply classify “no usable ECH configuration” as a reliable fingerprint.
Developers can also configure ECH globally or per domain, including disabling it where necessary.
That is a meaningful platform shift. But it also explains why installing Android 17 does not instantly guarantee that every connection from every app has its hostname hidden.
The biggest misconception: Android 17 support does not mean every app uses ECH today
There are at least three gates between the Android feature and a protected connection.
Gate 1: the app has to target the new platform behavior
Google documents the ECH behavior for apps targeting Android 17 / API 37 or higher.
That means the rollout depends partly on app developers updating their target SDK and shipping compatible versions. Older apps do not become modernized simply because the phone itself has been upgraded.
Gate 2: the networking library has to support Android's ECH APIs
Android apps do not all create network connections in the same way. Many rely on libraries such as OkHttp, WebView, HttpEngine, or custom networking stacks.
Google's documentation explicitly says ECH only becomes active when the networking library has integrated support. Google's August 27 security announcement specifically recommends that developers using OkHttp upgrade to OkHttp 5.5.0 and enable ECH.
This is why “Android 17 has ECH” and “this particular app connection used ECH” are two different statements.
Gate 3: the server has to support ECH
ECH also needs cooperation from the destination side.
RFC 9849 describes a server publishing an ECH configuration containing a public key and associated metadata. Android's ECH documentation notes that the client needs the relevant HTTPS DNS record/ECH configuration before it can protect the ClientHello in the intended way.
If the site or service has not deployed ECH, the phone cannot unilaterally encrypt an SNI field that the server does not know how to process.
So the practical coverage formula is:
Android 17 + app targets API 37 + ECH-capable network library + ECH-capable server
↓
hostname gets ECH protection
Miss one link, and the connection may not receive the full hostname-hiding benefit.
What ECH still does not hide
This is where privacy claims can easily become too strong.
The destination IP address
A network still needs to route packets somewhere, so the destination IP address remains visible to the network path in a normal direct connection.
An IP address does not always identify one website: large CDNs and hosting platforms can serve many domains from the same infrastructure. But in other cases an IP can still provide useful clues about the destination service.
ECH therefore makes domain-level observation harder; it does not make the destination network disappear.
Timing and traffic volume
A network observer can still see when a connection starts, roughly how long it lasts, and how much data moves.
Those signals are weaker than a plaintext hostname, but they are still metadata.
Anything an app deliberately sends elsewhere
ECH protects a TLS handshake field. It does not override analytics SDKs, account systems, advertising identifiers, application telemetry, or information that an app intentionally sends to its own servers.
Network privacy and app privacy are separate problems.
Malware or someone controlling the device
ECH protects against observers on the network path. It is not designed to protect against malicious software with access to the device, compromised apps, or someone who can inspect the device itself.
What Private DNS contributes
Google describes ECH as working in tandem with Private DNS because hiding SNI is less useful if the same network can simply read the DNS request immediately beforehand.
Android says Private DNS is enabled by default on networks that can use it, and Google recommends keeping it on.
The current Android settings path is:
Settings → Network & internet → Private DNS
The available options are:
- Off
- Automatic
- Private DNS provider hostname
Device manufacturers can change settings layouts, so searching Settings for “Private DNS” is the safer fallback if that path differs.
Google's warning is worth remembering: Private DNS protects only DNS questions and answers. That is exactly why ECH is complementary rather than redundant.
A practical privacy checklist for Android 17
There is no universal “turn on ECH” switch that guarantees every app and site uses the feature. The useful steps are more mundane.
1. Confirm the phone is actually on Android 17
Android 17 was released on June 16, 2026 and initially made available to most supported Pixel devices, with partner-device rollout depending on each manufacturer.
If a phone is still on Android 16 or earlier, Android's platform ECH support described here is not available.
2. Keep Private DNS enabled
For most users, leaving Private DNS on Automatic is the sensible baseline unless a specific network or provider setup requires something else.
Turning Private DNS off reopens one of the easiest ways for a network to observe domain lookups.
3. Keep browsers and network-heavy apps updated
ECH adoption depends on the app and its networking libraries. Updating Android but freezing applications on old versions can delay the practical benefit.
4. Do not assume a padlock means the hostname is hidden
HTTPS proves that the connection to the site is encrypted and authenticated when configured correctly. It does not, by itself, tell you whether ECH was negotiated.
“HTTPS is on” and “network observers cannot see the hostname” are not equivalent statements.
5. Use a VPN when the goal is broader local-network concealment
If the threat model is an untrusted hotel, airport, workplace, or public Wi‑Fi network and the goal is to hide direct destination connections from that local network, a reputable VPN can provide a broader tunnel.
That comes with a different trade-off: trust moves to the VPN provider, so provider reputation, logging practices, software quality, and configuration matter.
ECH's advantage is that it improves ordinary web privacy without introducing that extra routing intermediary for every protected connection.
A simple decision framework
The easiest way to decide what protection matters is to ask who you are trying to hide metadata from.
| Goal | Most relevant layer |
|---|---|
| Stop casual Wi‑Fi observers reading DNS requests | Private DNS |
| Stop classic TLS SNI from exposing the exact hostname | ECH |
| Protect the contents of the connection | HTTPS/TLS |
| Hide direct destination connections from the local Wi‑Fi | VPN or another encrypted tunnel |
| Stop an app company collecting data about activity inside its own app | App privacy controls/policy — ECH does not solve this |
That framework prevents a common mistake: treating every privacy technology as a different brand of the same thing.
What is confirmed—and what is still uncertain
Confirmed as of September 1, 2026
- Android 17 reached stable release on June 16, 2026.
- Android 17 includes platform support for Encrypted Client Hello.
- ECH encrypts the SNI and other sensitive ClientHello information defined by the TLS ECH standard.
- For apps targeting Android 17, ECH requires support from both the networking library and the remote server.
- Android lets developers configure ECH through
domainEncryption. - Google recommends using ECH together with Private DNS to reduce hostname metadata leakage.
- Android's Private DNS settings remain available under Network & internet and are on by default where supported.
Not guaranteed
Android 17 does not guarantee that:
- every installed app already uses ECH;
- every website or API server supports ECH;
- destination IP addresses are hidden;
- traffic timing and volume are hidden;
- the network learns nothing about the service being used;
- a VPN is unnecessary for every threat model;
- ECH makes a user anonymous.
Those distinctions matter more than the headline feature name.
What to watch next
ECH's real impact will depend on adoption rather than the Android API existing on paper.
Three signals are worth watching over the next several months:
- Networking-library adoption. Popular Android HTTP stacks need to integrate and ship the platform APIs broadly.
- Server and CDN adoption. More sites need to publish usable ECH configurations.
- App target-SDK migration. As more apps target API 37, Android 17's default ECH behavior can apply to a larger share of real traffic.
Coverage should therefore improve over time even without users learning a new protocol or toggling a special switch.
Conclusion
Android 17's ECH support closes a surprisingly important privacy gap.
HTTPS already hid what was being said. Private DNS could hide the DNS question. ECH can now hide the hostname inside the opening TLS handshake as well, making it harder for network operators and on-path snoopers to build a clean list of domains from supported connections.
But it is a layer, not an invisibility cloak.
The most accurate mental model is:
HTTPS protects content. Private DNS protects DNS lookups. ECH protects TLS hostname metadata. A VPN changes the visible network path.
Android 17 brings those first three layers closer together. Whether a specific connection receives the full benefit still depends on the app, its networking library, and the server on the other end.
Sources
Checked September 1, 2026:
- Google Security Blog — 4 new ways Android is protecting your network connections
- Android Developers — Android 17 behavior changes: Encrypted Client Hello
- Android Developers — Adopting Encrypted Client Hello
- Android Developers — Network Security Configuration: Encrypted Client Hello
- Android Help — Manage advanced network settings and Private DNS
- IETF / RFC Editor — RFC 9849: TLS Encrypted Client Hello
- Android Developers Blog — Android 17 is here