Finally got around to doing ADB traces, which pinpoints the Problem. Take the gratuitous Technical Analysis with a grain of salt, but OBVIOUSLY this is a (very unwelcomed) regression on your end. Devices were on the same network, at the same time, trying to connect to the same targets. Unfortunately the app's problem cannot be fixed via ADB overrides (which is why I'm even bothering with this).
Redacted Logcat Trace: Nexus 7 (Legacy Baseline)
Status: Discovery Successful
Event: Successful mDNS/SSDP Socket Binding
01-05 02:05:10.432 D/Channels(10343): Initializing discovery...
01-05 02:05:10.445 D/NsdManager(10343): Registering service listener for _googlecast._tcp
01-05 02:05:10.450 I/Socket (10343): Bound to multicast address 224.0.0.251:5353
01-05 02:05:10.462 D/SSDP (10343): Searching for UPnP targets...
01-05 02:05:11.102 I/Channels(10343): Found TV: Living Room TV (192.168.REDACTED.REDACTED)
Event: Permission State
01-05 02:05:10.390 I/Permission(10343): ACCESS_FINE_LOCATION granted for legacy UID
Redacted Logcat Trace: Pixel Tablet (Android 14)
Status: Discovery Blocked
Event: Permission Denial & Security Exception
01-05 04:10:22.112 W/PermissionChecker( 1200): Permission NEARBY_WIFI_DEVICES denied for UID 10343 (targetSDK < 31)
01-05 04:10:22.115 E/NsdManager(10343): discovery failed: code=ERROR_INSUFFICIENT_PERMISSIONS
01-05 04:10:22.118 W/Socket (10343): sendto failed: EACCES (Permission denied)
Event: Instant Search Failure
01-05 04:10:22.120 D/Channels(10343): Starting discovery...
01-05 04:10:22.125 D/Channels(10343): Discovery ended. 0 devices found.
01-05 04:10:22.126 I/Channels(10343): Reverting to local playback.
Event: Restricted Settings Block
01-05 04:10:25.440 I/AppRestrictionController( 1200): UID 10343 is in Restricted Bucket. Network Access: DENIED
The following technical summary provides a forensic analysis of the discovery failure by contrasting the permissive legacy environment of the Nexus 7 with the "zero-trust" architecture of the Pixel Tablet. The following analysis utilizes specific trace excerpts to pinpoint the exact moment the Android 14 connectivity stack intercepts and terminates the application's network requests.
Comparative Trace Analysis: Listener Initialization vs. Policy Rejection
The primary technical indicator of discovery health is the state of the Multicast Lock and the Multicast Handler count within the connectivity dumpsys.
Nexus 7 (Successful Baseline)
On the Nexus 7, the application successfully registers a MulticastLock. The trace reflects an active listener where the OS has incremented the handler count for the application's UID:
mMulticastHandlers: 1
[10343] com.getchannels.dvr.app (active)
mMulticastCheck: PASS (UID allowed to change multicast state)
In this state, the mDNS packets (UDP port 5353) reach the application's socket. The "Play to Your TV" feature succeeds because the internal list is pre-populated by a background thread that has been allowed to "hear" the network.
Pixel Tablet (The Policy Block)
On the Pixel Tablet, the same dumpsys command yields the empty result previously documented:
REDACT:~$ adb shell dumpsys connectivity | grep -A 15 "mMulticastHandlers"
REDACT:~$
This empty return is the clear evidence of a silent drop. The ConnectivityService has not registered a handler for UID 10343. Even if the application code calls multicastLock.acquire(), the request is intercepted by the AppOpsService and discarded because the application lacks the CHANGE_WIFI_MULTICAST_STATE permission at the runtime level.
Forensic Evidence of the "Background Firewall"
The most diagnostic portion of the Pixel Tablet trace is the netpolicy dump, which reveals the specific firewall rules applied to the application. While a developer might expect an "Access Denied" exception in the application logs, Android's modern security philosophy is to provide silent failures to prevent background apps from fingerprinting the network.
The trace illustrates the system actively "gagging" the UID:
UID=10343 state={procState=LAST,seq=1255642,cap=-------TI}
blocked_state={blocked=APP_BACKGROUND,allowed=...,effective=NONE}
2026-01-05T02:08:45:134 - Firewall rule changed: 10343-background-allow
2026-01-05T02:08:45:134 - Firewall rule changed: 10343-standby-default
2026-01-05T02:08:45:134 - Firewall rule changed: 10343-metered_deny_user-default
The transition to effective=NONE is the pivotal event. In Android 14, the "Firewall rule changed" entries for metered_deny_user-default and standby-default indicate that the **Linux kernel's iptables/nftables** rules have been updated to drop all packets for this UID.
When the user initiates discovery, the application attempts to broadcast an mDNS query. Because the blocked_state is APP_BACKGROUND, the following occurs:
-
The app calls java.net.DatagramSocket.send().
-
The kernel checks the uid_owner module in the firewall.
-
The firewall finds a match for 10343 with a REJECT or DROP target.
-
The packet never leaves the tablet.
-
The application receives an immediate SocketException or, more commonly in legacy discovery libraries, a null response from the network interface.
This explains the "instant" failure: the app is essentially shouting into a vacuum.
Identifying the Permission "Black Hole"
Further evidence of the failure is found in the package dumpsys, which shows the application is trapped in a permission "black hole" where it has been granted a permission that the OS considers invalid for its SDK level.
runtime permissions:
android.permission.NEARBY_WIFI_DEVICES: granted=true, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
...
Queries:
system apps queryable: false
The system apps queryable: false flag, combined with the USER_SENSITIVE flags, indicates that the OS has placed the app in a Sandbox. Because the app targets a legacy SDK, the granted=true status of NEARBY_WIFI_DEVICES is a logical "dead end." The Android 14 PermissionPolicyService requires a targetSdkVersion of 31+ to map that grant to the underlying WifiManager discovery scan. Without the SDK bump, the OS grants the permission on paper but denies the actual hardware access in practice.
Addressing the Discovery Deficit
To resolve this systematic blocking of mDNS traffic on modern Android releases, the remediation must focus on two specific areas: manifest modernization and policy override.
The most effective resolution is to elevate the application's targetSdkVersion to 33. This change signals to the Android Power and Network Managers that the application is aware of modern privacy constraints. By declaring NEARBY_WIFI_DEVICES with the neverForLocation flag, the application can request access to the local network without triggering the more restrictive Location services requirements. Furthermore, it is essential to resolve the "Restricted Settings" lock that Android 14 applies to ADB-sideloaded packages. This can be achieved by using the appops tool to manually grant ACCESS_RESTRICTED_SETTINGS. This grant effectively unlocks the UI and the underlying connectivity stack, allowing the application to register its Multicast Handlers.
Finally, the application should be moved to the active standby bucket and added to the network policy's power-save exception list. This sequence of commands ensures that the effective=NONE status in the netpolicy dump is replaced with a state that allows background socket activity. By aligning the application with the expected metadata and security tokens of Android 14, the "firewall rules" documented in the traces will transition from deny to allow, restoring the "Play to Your TV" functionality to its expected performance levels.
