Android 17 Local Network Permission: TV, Printer & NAS Fixes

Your phone can load websites, stream music and receive messages, but the printer has disappeared. Or a media app no longer sees the TV that worked yesterday.

That combination is frustrating because Wi-Fi looks healthy. It may actually be healthy. Reaching the internet and reaching another device inside your home are different jobs.

On Android 17, an app targeting Android 17/API 37 or later may need the new local-network permission before it can discover or connect to devices on your network. Older-targeting apps and apps using certain system device pickers follow different rules. A missing TV is therefore a reason to check permissions, not proof that Android has blocked your entire home network.source 1

Start with the app that fails. Do not factory-reset the phone or reset the printer yet.

First, identify which part stopped working

Try one device and one app at a time. The following checks are a diagnosis plan, not a claim that every symptom has only one cause.

What you observe	What it suggests	The next useful check
One app cannot find the TV, but another app can	An app-specific permission, discovery method or compatibility problem	Inspect the failing app's permissions and update history
No phone on the network can find the printer	The printer or network deserves attention first	Confirm the printer is online and connected to the intended network
A NAS opens by its known local address, but automatic discovery is empty	Discovery and direct connections are behaving differently	Investigate app discovery, multicast and name resolution
The phone works on your main Wi-Fi but not guest Wi-Fi	Network isolation is a plausible explanation	Use the trusted main network rather than weakening guest-network security
The problem appears only with a VPN connected	VPN routing or a local-network exception may be involved	Compare the same test with and without the VPN on a trusted network
Devices appear, but connecting produces an authentication error	Discovery succeeded; credentials or the service may be failing	Check the device account and service configuration

Write down the failing app's version and the phone's Android build. “Android 17 broke casting” is much less useful than “app version X stopped discovering this TV after its own update.”

What the Android 17 permission actually changes

The permission is named ACCESS_LOCAL_NETWORK. Google places it in the nearby-devices permission group. It covers direct local-network communication, including relevant TCP connections, UDP traffic and local discovery. A WebView does not get a separate exemption from its host app's permissions.source 1

Two details prevent a lot of unnecessary troubleshooting:

The app's target SDK matters. Android 17 does not put every installed app into the same new permission state just because the phone was upgraded.

A system picker may handle device selection instead. Google's documentation describes approaches such as the Cast Output Switcher and a system-mediated network-service picker. An app using an eligible approach does not necessarily need broad access to every device on the LAN.source 1

Do not expect identical prompts in two different casting apps. Different implementation choices can produce different permission experiences.

Why an app update can trigger the problem later

A phone upgrade and an app compatibility change do not have to happen on the same day. An app can change the Android version it targets in a later release.

For troubleshooting, record both events separately. When something breaks, check whether the phone updated, the app updated, the router changed, or the receiving device installed new firmware. Treat the last change as a clue, not a verdict.

Check the failing app's permissions

Open the app's information page in Android Settings, then inspect Permissions. Look for a local-network or nearby-devices permission relevant to the feature. Exact wording and grouping can vary by build.

If access is denied, and this is an app you deliberately use to communicate with your own TV, printer or NAS, grant the relevant access. Close and reopen the app, return to its device-discovery screen and repeat the same test.

There is no reason to grant unrelated microphone, contacts or all-files access to diagnose a missing printer.

What if there is no permission to enable?

Do not assume a hidden switch must exist. The app may not request the permission, may use a different supported discovery path, or may not yet have implemented the change correctly.

Use the app's normal “add device,” “find printer,” or “connect to server” action once. A permission request may be connected to that action rather than shown at startup. If no relevant request or setting appears, check the maintainer's release notes and issue tracker.

Avoid copying commands that try to grant a permission the app never declared. An Android 16 developer-testing command is also not a general Android 17 consumer fix.

A real example: Kodi's Android 17 local-network issue

A July 2026 Kodi issue reported blocked local-network access on a Kodi v22 Beta 1 nightly targeting API 37, running on GrapheneOS based on Android 17. The report identified a missing permission declaration. The issue was subsequently closed with a fixed-resolution label and linked development work.source 2

That is useful evidence of a specific compatibility problem. It is not evidence that every Kodi release, every Android 17 phone or every casting app is broken.

The practical lesson is to identify the exact app build before changing the network. If the fault is in the app's permission implementation, resetting a working router cannot add the missing declaration. Check which released build contains the correction rather than assuming an issue marked “fixed” has already reached your installed channel.

Check guest Wi-Fi and client isolation

A guest network can provide internet access while deliberately preventing devices from talking to one another. Google explicitly identifies AP or client isolation as a setup problem for its streaming devices.source 3

Check the network shown on the phone and on the receiving device. A printer connected to the main household network may be unreachable from a phone on an isolated guest network even when the Wi-Fi names look related.

Connect both devices to a network you own and trust. On a hotel, office or campus network, ask the administrator whether local device discovery is allowed. Do not disable someone else's network isolation or expose a printer to the internet.

Must both devices use 2.4 GHz?

Not automatically. The important question is whether the router allows communication between the two devices, not whether their radio bands match.

A setup wizard may require a particular band for a particular product. Follow that product's instructions. But moving every device to 2.4 GHz is not a universal repair for a permission problem or an isolated guest network.

Separate discovery from an actual connection

Device discovery answers “what is available?” A connection answers “can this app reach and use that service?”

If your NAS or printer has a documented local web interface, open its known address from a browser. Obtain that address from the device's own display, its official management app or your router's client list. Do not guess a random address from an online guide.

Then compare the results:

Browser access works, discovery fails: investigate discovery or the failing app before treating the device as offline.
The browser and the app both fail: check the network path, the receiving device and each app's applicable permissions.
Discovery works, sign-in fails: inspect the service account or credentials instead of repeatedly changing discovery settings.

A successful browser test proves that the browser reached that endpoint. It does not prove that a different app has the same permissions, uses the same protocol or can reach a different port.

For a NAS, use the service and address format documented by its manufacturer. Do not enable an obsolete file-sharing protocol just because a forum comment says it made discovery easier.

Test VPN and filtering software without dismantling your setup

On your trusted home network, repeat the failing action with the VPN temporarily disconnected. Restore it afterwards. If your work profile or organization controls the VPN, ask the administrator rather than attempting to bypass it.

If the result changes, inspect the VPN's documented local-network or split-tunneling settings. “Allow LAN” is not a setting with identical behavior in every VPN, and some products intentionally block access to nearby devices.

Keep the test narrow. Turning off the VPN, firewall, DNS filter and every privacy setting together makes it impossible to identify which change mattered.

Also separate a VPN from a DNS problem. A manually entered local IP address and a device name ending in .local are not the same test. Record which one succeeds.

Update the component that evidence points to

When only one app fails, update that app from its legitimate distribution channel and check its recent issues. When every client fails, investigate the receiving device and router instead.

A sensible order is:

Reopen the failing app after checking its permissions.
Confirm the receiving device is awake and on the intended network.
Repeat the test with another already-trusted app or device.
Check the relevant app, device and router release notes.
Restart the component whose behavior remains suspect, then retest.

A restart can clear a temporary condition, but it does not explain the cause. If the same problem returns, preserve the app version, network and timing details rather than repeating increasingly destructive resets.

What to send the app developer

A useful report is short enough to reproduce:

Phone model and Android build:
App name, version and installation source:
Stock Android or named custom OS:
Device being discovered and its firmware:
Main Wi-Fi or guest Wi-Fi:
Relevant permission shown, granted or missing:
VPN enabled during the test:
Does another app or phone work?
Does a documented direct local address work?
Exact error and steps that reproduce it:

Remove passwords, account identifiers and anything identifying a private network before posting screenshots publicly. A maintainer usually needs the error and configuration, not your NAS credentials.

If the app will not install at all, use the separate APK installation troubleshooting guide. Permissions inside an installed app cannot repair an incomplete or incompatible installation package.

Frequently asked questions

Does Android 17 block all casting apps?

No. The permission requirement depends on the app's target and implementation. System-mediated casting or device selection can also differ from an app's own LAN discovery.source 1

Why does YouTube see my TV while another app does not?

That comparison narrows the problem but does not establish the cause. The apps may use different discovery paths, permissions or account-based features. Check the failing app rather than assuming the TV must be faulty.

Will clearing the app's cache fix a missing permission?

Do not use cache clearing as a substitute for examining the permission. First identify whether access is denied, the request is missing, or the connection fails after discovery. Avoid clearing app storage unless you understand which saved devices, accounts or settings it would remove.

Should I reset network settings?

Not as the opening move. It changes more than the single app you are investigating. Google's Pixel guidance notes that resetting Bluetooth and Wi-Fi removes saved Wi-Fi connections.source 4 Preserve your network details and try the narrower checks first.

The best first move

Before you change anything, answer this: does the problem follow the app, the phone, or the network?

That one comparison is often more useful than a long list of “Wi-Fi fixes.” Then check the relevant permission, record one change and repeat the same test. Keep working internet access intact while you diagnose the local connection.

Sources and scope

This guide combines official Android documentation, a specific maintainer issue and a diagnostic workflow. It does not claim hands-on verification across Android 17 devices. Documentation and the issue status were checked on September 28, 2026.

Source 1: Android Developers, “Local network permission.” Target-SDK behavior, permission group, covered traffic and system-picker alternatives. Open source
Source 2: Kodi issue #28557, “Android 17: Kodi v22 BETA1 nightly is missing ACCESS_LOCAL_NETWORK permission,” opened July 7, 2026. The reported environment is specific; a closed issue does not establish which public release the reader has installed. Open source
Source 3: Google streaming-device help, router settings and AP/client isolation. Open source
Source 4: Google Pixel Help, “Fix mobile connectivity issues,” network-reset consequences. Open source