Android 17 Beta 3 Location Privacy: GPS and Network Changes

Android 17 Beta 3, released this week, introduces two privacy changes that together redefine what Android treats as a location problem. The first is a system-rendered button that gives apps precise location access for the current session only, no permission dialog required. The second makes it mandatory for apps targeting SDK 37 or higher to get explicit runtime permission before exchanging any traffic with devices on the local network. Android 17 Beta 3 location privacy, in other words, now covers both GPS coordinates and the routers, smart TVs, and speakers sitting on your home network.

That framing matters. GPS access and local network access have always been separate permission categories, but they expose the same thing: where you are. Android 17 is starting to treat them accordingly.

What the new location button does and how it differs from existing options

Android already offers three choices in its standard location permission flow: "Only this time," "While using the app," and "Always." The new button is not a fourth variant of that dialog. It replaces the dialog entirely for session-scoped access.

Here is the practical distinction. With "Only this time," the system still interrupts the user with a modal prompt, and the user must make an active choice before the app gets anything. With the new location button, the button is embedded in the app's own interface via Jetpack, and tapping it directly grants precise location access without any intervening dialog. The button is session-scoped and contextual: the user taps it when they need it, the app gets access, and when the session ends, the permission expires. No carry-over, no persistent grant.

The other critical difference is who controls the UI. Because the system renders the button rather than the app, developers cannot freely restyle it or control its presentation the way they would a normal in-app button. Google owns how it looks and where it can appear, per the release notes. That constraint is what makes the lower-friction model trustworthy: the user is tapping something the platform vouches for, not something the app designed to maximize conversions.

Integrating the button requires declaring the new USE_LOCATION_BUTTON permission, according to the release notes. One thing the release notes do not yet define is where exactly a session boundary falls, or whether access can be cut mid-session. That detail matters for a complete privacy assessment, and Beta 3 is not the final word on it.

Why Android 17 Beta 3 location privacy now includes your local network

An app that has never asked for location access can still figure out roughly where you are. Any app holding a standard internet permission can currently communicate freely with every device on the same local network: the router, a smart speaker, a streaming stick, a connected thermostat. Google's documentation states the problem directly: that open access lets apps build a fingerprint of the user and functions as a proxy for physical location. The combination of visible devices on a network, their names, types, and manufacturers, can place a user in a specific home or office without a single GPS coordinate changing hands.

Android 17 closes that gap. The ACCESS_LOCAL_NETWORK runtime permission is now mandatory for apps targeting SDK 37 or higher, and enforcement covers all traffic to and from local network addresses, not just device discovery but the actual data exchange, per the documentation. Android 16 introduced this framework as an opt-in feature; only apps that chose to participate were affected. Android 17 makes it the rule.

Locking down GPS access while leaving network-based location inference open would be an incomplete fix. The two changes address the same underlying problem from opposite directions: one limits how long a precise location signal can be held, the other gates access to a coarser but equally revealing one.

Where users and developers will feel the friction

The most immediate real-world impact lands on media casting. Google explicitly identifies casting as a category that depends on local network access and will be affected by mandatory enforcement, per the documentation. Apps that discover smart TVs, speakers, or Chromecast-style devices will need to request ACCESS_LOCAL_NETWORK before exchanging any traffic with them. If the user denies that permission, the app gets another opportunity to explain its rationale and ask again.

There is a designed-in escape hatch:

• Apps that use Output Switcher as their in-app casting interface will not need the local network permission at all. Google has indicated that fuller guidance on this path is coming in a later release, per the documentation.
• For developers, adopting Output Switcher is the path of least friction, but it requires integrating a specific Google-provided component rather than handling device discovery independently.

The rollout is graduated by design. Android 17 uses a split migration strategy that applies different enforcement rules depending on an app's target SDK, handling legacy apps separately from those newly targeting Android 17, according to the documentation. At launch, the experience will be uneven. Some apps will show new permission prompts where none existed before; others will look exactly the same, depending entirely on whether the developer has updated their target SDK.

The net effect on users runs in two opposite directions at once. In apps that adopt the new location button, the experience gets simpler: a tap instead of a dialog, and no lingering permission grant. In apps that rely on local network access and haven't yet migrated, new prompts will appear where none existed before. Less friction in one place, more in another, depending on which app you're in.

What these changes mean now and over time

Neither change reaches most users until developers update their target SDK and integrate the new components. Android 17 is still in beta, and enforcement follows adoption. Users running Android 17 at launch will encounter these changes selectively, not universally, per the release notes and local network permission documentation.

The longer-term pattern is more significant than any single feature. Android is progressively narrowing what apps can access without active, contextual user consent: first camera and microphone, then location, now network-based signals that can serve the same surveillance function as location data. The local network permission follows the same runtime model already applied to sensitive hardware access: revocable, re-requestable, and requiring developers to articulate their rationale when users push back.

The metric worth watching as Android 17 moves toward a stable release is casting compatibility. If Google's Output Switcher guidance arrives clearly and developers adopt it ahead of enforcement, the transition will be smooth enough that most users never notice the underlying change. If that guidance is delayed or incomplete, a wave of unfamiliar permission prompts in familiar apps is the more likely outcome. Android 17 won't be final for months, and that question is still open.