It took me a while to figure out why many of my self-hosted services were intermittently failing to connect on my phone after updating to Android 17. I eventually figured out there’s a new ACCESS_LOCAL_NETWORK permission which means the “Nearby devices” permission is now required to access devices on the same network subnet. For an avid self-hoster, this can be quite a bit.
I had my DNS configured so my public-facing server resolved to a local IP address when on my LAN. This meant that my web, immich, xmpp, NTP, jellyfin and DoH servers all resolved to a local IP address on wifi. On Android 17, it all broke without warning. No error messages. No asking for extra permissions. Just silent packet dropping.
I’ve solved it by configuring my public-facing services to resolve to my external (static) IP address, even when inside the network. I couldn’t make any internal services resolve to the external address (SMB, CUPS etc) because they are (obviously) not bound to my WAN interface.
I get why the change was made. A lot of apps were snooping around people’s networks to gather intel. A potentially massive privacy violation.
Has anyone else had this issue? Is this the cleanest solution?
Luckily grapheneos allows a hybrid approach so allows just the lan subnet permission without the wider nearby devices permission.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DHCP Dynamic Host Configuration Protocol, automates assignment of IPs when connecting to a network DNS Domain Name Service/System ISP Internet Service Provider NAT Network Address Translation PiHole Network-wide ad-blocker (DNS sinkhole) XMPP Extensible Messaging and Presence Protocol (‘Jabber’) for open instant messaging
[Thread #115 for this comm, first seen 27th Sep 2026, 20:10] [FAQ] [Full list] [Contact] [Source code]
I had my DNS configured so my public-facing server resolved to a local IP address when on my LAN. This meant that my web, immich, xmpp, NTP, jellyfin and DoH servers all resolved to a local IP address on wifi.
I unfortunately don’t have an answer to your question since I’m not on Android 17, but I do want to ask about this part. What’s the benefit of this? Does it improve speed when streaming on Jellyfin?
Not OP but I do the same for two reasons.
A) it eleimitaes my ISP traffic. It doesn’t have to go out to my router, to come back in on the public IP. They can’t track what never hits them.
B) I also have completely internal services. So the DNS entries are internal only. Can’t map my internal network publicly.
Would you have any recommendations to resources where I can read about setting something like this up? I’ve recently picked up a managed switch and set up a computer to act as a router, and I’ve been learning how VLANs be. I don’t have things fully working on my home network yet, though, but I’m very interested!
I don’t know how the others set theirs up, but I use “views” in bind 9 https://kb.isc.org/docs/aa-00851
Essentially, the DNS I run on a router-like box much like you describe uses a different database depending on whether you query from an internal IP address or a public address. For me, the advantages are that I can let devices on my local network declare their own names to DHCP and enter them in DNS without worrying about the outside world. Mu internal network doesn’t crash if my ISP changes my address, Certbot happily requests certs for any site with a public address, and that cert works seamlessly on the corresponding internal address, no wildcards or DNS challenge required.
That’s so sick! That’s definitely above my skill level at the moment, but I will save this for when I’m more knowledgeable—thank you much!
What are you running on your router? If you use opnsense, I’m pretty sure it has a GUI for DNS stuff. Been a while since I’ve used it.
If you use pihole for DNS, you can set it up in there too, but it’s not the same process as most other systems.
A router shouldn’t be sending that traffic outside. It should already have routes to send it right back, either regular or NAT rules.
Why are permissions so damn confusing? I say this as someone who knows why permissions are needed, such as location to find nearby devices. But why must we keep track of “permission X is for thing unrelated to X” in our heads? Now I haven’t tried to make a permissions system for the masses, so I guess I can’t say too much, but it doesn’t seem that difficult to just make the permission name relate to what it does and provide a short synopsis for it.
Google tries to make permissions easy to understand for end users, instead of making them detailed for tech people. The permissions “nearby devices” covers any method for reaching out to nearby devices. Previously, you had the permission “location”, which contained some ways of local access.
An app requiring nearby devices to connect to a bluethooth or other nearby device is more clear than an application requesting your location.
Devices in the LAN are also considered devices near you. For dumb end users, silently blocking it is more secure than showing a dialog, as people are dialog fatigued today.
Why not just grant the permission to the apps?
Relatedly, I think this is why Google Home and casting to Chromecast have stopped working reliably on my phone. Anyone figure those out? I’ve already tried granting permissions. Or it may be something GrapheneOS is doing.
