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:

  1. DNS: the device asks how to reach a domain such as example.com.
  2. 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.

ProtectionWhat it mainly hides from the local networkWhat the local network can still observeMain dependency
HTTPS onlyPage contents, messages, passwords, URL pathsDNS lookups may reveal domains; classic SNI may reveal hostname; destination IP and traffic patterns remain visibleSite supports HTTPS
Private DNSDNS questions and answers when Private DNS is activeTLS hostname can still leak without ECH; destination IP and traffic patterns remain visiblePrivate DNS availability/configuration
ECH + Private DNSTwo major hostname leaks: DNS queries and TLS SNI, for supported connectionsDestination IP, timing, volume, and other network metadataApp/network library + server + ECH configuration
VPNThe local Wi‑Fi generally sees an encrypted tunnel to the VPN rather than each destination connectionIt can still see that a VPN is in use, the VPN endpoint, timing, and traffic volumeVPN 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.

GoalMost relevant layer
Stop casual Wi‑Fi observers reading DNS requestsPrivate DNS
Stop classic TLS SNI from exposing the exact hostnameECH
Protect the contents of the connectionHTTPS/TLS
Hide direct destination connections from the local Wi‑FiVPN or another encrypted tunnel
Stop an app company collecting data about activity inside its own appApp 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:

  1. Networking-library adoption. Popular Android HTTP stacks need to integrate and ship the platform APIs broadly.
  2. Server and CDN adoption. More sites need to publish usable ECH configurations.
  3. 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:

Written and reviewed by /lico

Just writing down my thoughts, interests, and the things I learn along the way.