On August 27, 2026, Google announced four network protections introduced in Android 17. Among the changes affecting home Wi-Fi, apps now must request user permission before searching for other devices on the same network, such as TVs, printers, and cameras. Previously, the "internet" permission—granted for connecting to external web services—also served as a de facto pass to the home LAN. Android 17 separates these two permissions, but a device's update date doesn't automatically revoke every app's existing pass.
What a 399-App Study Revealed About Unauthorized Access
On local networks, devices like smart TVs and network cameras broadcast their presence and available services. The same mechanism is used by everything from game consoles to speakers and printers. While convenient for casting or printing, the combination of device names and services can sketch out a household's profile. Google itself has explained that unrestricted LAN access can serve as an alternative method for identifying households based on device configuration or inferring their location.
The risks aren't merely theoretical. A peer-reviewed 2025 study manually examined 399 Android apps across 854 tests, finding unexpected LAN access in 89 apps and network scanning in 93. Among the 124 apps that accessed the LAN, 100 initiated communication before users had agreed to the privacy policy. The paper, "LANShield," published in Proceedings on Privacy Enhancing Technologies, tested apps by varying foreground/background behavior, privacy policy consent status, and runtime permissions.
| Survey Item | Result |
|---|---|
| Apps manually examined | 399 |
| Number of tests | 854 |
| Unexpected LAN access confirmed | 89 apps |
| Local network scanning confirmed | 93 apps |
| LAN communication initiated before policy consent | 100 of 124 (80.6%) |
The 399 apps were a non-random sample drawn from five categories, so the results cannot be generalized to the overall incidence rate across the entire Google Play store. Nor does this mean all 89 apps were malicious—the classification of "unexpected" communication was based on researchers' assessment relative to the app's stated function and user actions. Still, the fact that 93 apps scanned the LAN, and that 80.6% of the 124 apps connecting to the LAN did so before user consent, demonstrates that the scope of the internet permission was too broad.
The research team also built several proof-of-concept exploits using a malicious app possessing only the internet permission: extracting information from the LAN, intercepting device-discovery traffic to hijack communication paths, and directly attacking devices on the LAN. This doesn't mean the surveyed apps were executing these same attacks. However, it confirmed an attack surface where a smartphone app on the same Wi-Fi network could reach devices from the inside—devices that are otherwise protected from external access by the router.
Android 17 Separates LAN Access at a Deep Socket Level
The newly introduced ACCESS_LOCAL_NETWORK permission in Android 17 isn't limited to blocking specific device-discovery APIs. It covers outbound and inbound TCP connections, as well as UDP unicast, multicast, and broadcast transmission and reception. The restriction extends beyond code that opens sockets directly to libraries like Cronet and OkHttp, and to APIs built on top of them.
The same applies to device discovery pathways. Multicast DNS (mDNS), Simple Service Discovery Protocol (SSDP), Android's NsdManager, and name resolution for addresses ending in .local all now require the local network permission. To prevent apps from bypassing the restriction simply by switching to a different API, Google evaluates communication at a deep layer of the network stack.
However, this isn't a mechanism that blocks all device communication outright. An exception exists for communication with a DNS server on the LAN over port 53. Apps can also connect without the broader permission to a device address that the user has selected through an OS-mediated device selection screen. What Android 17 adds isn't a ban on LAN access—it's a boundary that unbundles the assumption that "an app capable of connecting to the external internet can also reach every device on the home network."
Google also introduced Encrypted Client Hello (ECH), certificate transparency by default, and carrier-driven default disabling of 2G—each protecting a different aspect of communication. ECH addresses exposure of visited domains, certificate transparency addresses fraudulent certificates, and 2G controls address downgrade attacks via fake base stations. What the local network protection closes off specifically is the pathway from an app on the device to the same LAN.
Old Passes Remain Valid Until Apps Update to API 37
Android's LAN protection began as an optional developer trial in Android 16 and became mandatory for apps targeting API 37 in Android 17. However, starting August 31, 2026, Google Play's minimum requirement for new apps and updates is API 36—meaning a mass migration to API 37 is not required at the OS's launch. By comparison, iOS introduced a similar user permission requirement back in iOS 14.
Even on an Android 17 device, apps targeting API 36 or lower can continue accessing the LAN as before. To maintain compatibility, Google implicitly grants these apps the ACCESS_LOCAL_NETWORK permission alongside their existing internet permission. The protection only becomes mandatory once a developer raises the app's target to Android 17's API 37 or higher.
This transition actually began with Android 16, which let developers optionally test local network protections and temporarily use the NEARBY_WIFI_DEVICES permission to identify dependencies. Android 17 replaced that trial with the formal ACCESS_LOCAL_NETWORK permission and made it mandatory for apps targeting API 37.
This creates a gap in adoption. As of August 31, 2026, Google Play's minimum requirement for new apps and updates is Android 16's API 36 or higher—API 37 is not currently a submission requirement. Developers can migrate ahead of schedule, but apps that merely meet the store's baseline requirement can remain on API 36 for the time being. As of September 1, Google's official documentation does not list a date for when API 37 will become mandatory on Google Play.
Therefore, the claim that "Android 17 prevents apps from scanning home LANs without permission" comes with a caveat. It holds true for apps that have migrated to API 37. But for existing apps still targeting API 36 or lower, the old pass remains valid. From a user's perspective, the scope of protection depends on the combination of the device's OS version and each app's target API.
A Design That Lets Users Pick Devices Without More Permission Prompts
Developers now have two paths. Apps that need broad, ongoing access to multiple devices on the LAN—such as smart home management apps—should declare ACCESS_LOCAL_NETWORK and request permission at runtime. They must also handle scenarios where the permission is denied or later revoked, meaning communication becomes unavailable.
For simpler use cases—like streaming video to a single TV or selecting one specific service—apps can use an OS-mediated device selection screen instead. Apps supporting Google Cast can use the output switching screen, while apps searching for generic devices via mDNS can invoke the NsdManager selection screen. Since the OS displays candidates and only passes the user's selected connection to the app, there's no need to request broad permission to view the entire LAN.
This design carries significance beyond simply reducing the number of permission prompts. It allows users to select a single device they want to connect to, rather than blanket-approving "access to nearby devices." It's conceptually similar to sharing only selected photos with an app rather than granting it access to view an entire photo library.
That said, ACCESS_LOCAL_NETWORK falls under the existing NEARBY_DEVICES permission group. If a user has already granted another permission in that same group—such as Bluetooth—no new confirmation screen will appear for local network access. Even though the communication itself is technically controlled, users aren't necessarily made aware that a new permission has been added. Apps requesting broad permissions need to clearly explain on-screen which devices they're connecting to and for what purpose.
Six Years After iOS 14, What Determines Real-World Adoption
Apple introduced Local Network Privacy in 2020 with iOS 14, adopting an approach where apps prompt users for confirmation the first time they attempt to access the LAN. Android's move to formal enforcement came six years later, with Android 17 in 2026. Android chose a path of gradual migration tied to target APIs while maintaining backward compatibility.
Even the earlier system wasn't foolproof. The LANShield paper analyzed iOS's protection mechanism and reported several methods for bypassing the permission requirement. Android 17's developer documentation similarly acknowledges exceptions—DNS traffic, user-selected devices, and implicit grants for legacy apps. The presence of a permission shouldn't be mistaken for a guarantee against all LAN-based attacks.
Measuring Android 17's real-world effectiveness will require more than just OS adoption rates. Key indicators include the proportion of apps that have migrated to API 37, the number of device-connectivity apps that adopt OS-mediated selection screens rather than broad permissions, and whether independent testing—covering VPNs, IPv6, and multiple subnets—confirms that bypass methods remain closed off. Only once these conditions are met will the home LAN truly be integrated into Android's permission model as a private space distinct from the external internet.