Docs

Android 17 Local Network Permission Tracking

Android 17 blocks local network access behind a new runtime permission — what to track before pairing and cross-device attribution silently drop.

Acquisition

Android 17 makes local network access opt-in by default. Any app that talks to devices on the same Wi-Fi network — a raw socket connection, mDNS discovery, SSDP — now needs the new ACCESS_LOCAL_NETWORK runtime permission once it targets SDK 37 or higher, and until the user grants it, those connections simply don’t happen. That’s a bigger deal than it sounds for anything built around device pairing: smart TV casting, smart home setup flows, printer discovery, and — less obviously — the cross-device attribution tricks some growth teams use to link a phone install to a companion app already running on the same network.

The trap is that this looks like a functionality regression when it’s often a plumbing change. Android also shipped a system-run device picker (NsdManager with DiscoveryRequest#FLAG_SHOW_PICKER) that lets a user select one device from a system dialog without the app ever requesting the broad permission at all. Apps that migrate to the picker keep working exactly as before, invisibly, with no permission prompt and no grant-rate to track. Apps that don’t migrate will show a real drop in permission grants and a real drop in discovery success — and from a dashboard alone, those two outcomes look identical.

Data Points to Track

  • ACCESS_LOCAL_NETWORK request outcome (granted / denied / not shown), segmented by app version and target SDK, so you can tell which builds are even asking
  • Local discovery success rate, split by permission-based flow vs. picker-based (FLAG_SHOW_PICKER) flow — these should not be blended into one number
  • Time-to-first-successful-local-connection for pairing, casting, and setup flows, compared pre- and post-Android 17 rollout
  • Fallback rate: sessions where local discovery fails and the user is pushed to manual pairing (QR code, PIN entry, manual IP)
  • OS version distribution of every local-network-dependent feature, so a permission-driven drop can be isolated to Android 17 devices specifically

Setup Steps

  1. Audit for raw local-network usage — direct sockets, mDNS/SSDP libraries, or NsdManager calls without FLAG_SHOW_PICKER — and migrate discovery flows to the system picker wherever a full permission isn’t strictly necessary.
  2. Instrument the permission outcome as its own event, separate from whatever discovery-success event already exists, so a denial and a discovery failure aren’t conflated.
  3. Tag every local-network-dependent flow with target SDK version to build clean pre/post-17 cohorts rather than relying on OS version alone.
  4. Add an explicit fallback-path event for manual pairing, and track how often users take it after local discovery fails.
  5. Test on an SDK 37+ device to confirm picker-based flows genuinely skip the runtime prompt, rather than assuming the migration worked from code review alone.

Actionable Insights

A falling ACCESS_LOCAL_NETWORK grant rate is not automatically lost functionality — if the flow already runs through the system picker, it never needed the permission, and the grant-rate metric will just go to zero while feature completion stays flat. Watch completion rate for the pairing or casting flow itself as the ground truth, not permission grants as a proxy for it. Where discovery genuinely does depend on the broad permission, expect denial rates to be meaningfully higher than users have historically shown for narrower, single-purpose prompts — a blanket “let this app access your local network” ask reads as far riskier than picking one named device from a system list.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert