Yes, two years ago this problem was brought up, but it didn't get any resolution. I don't think many Android users really know anything about this feature.
Yes, I remember that thread, which is why I am disappointed this is still an issue 2 years later. When my Harmony Elite finally gives up the ghost, I now have no backup plan -- was going to simply deploy Channels on cheap Tablets (with whatever device control companion I needed).
So there "is" theoretically an ADB workaround here, but I did not get it to work. It is specific to my (Pixel) Tablet. I may take one more pass thru refining it. For those interested (and it lends some insight into the problem), I've posted a summary of the steps below. For an annotated write-up, you can look at this Gist (hit "Preview" if Markdown doesn't render). (Edit: Failure was due to OS refusing to perform some of the commands because (a) the app had targeted such as old SDK, and (b) the app's MANIFEST (AndroidManifest.xml) had to have certain required flags for some of the commands to be honored, such as, NEARBY_WIFI_DEVICES - again, a case of too old SDK here).
# --- STEP 1: IDENTIFICATION ---
# Identify the current User ID (UID) assigned to the app (e.g., 10343)
adb shell pm list packages -U com.getchannels.dvr.app
# --- STEP 2: PERMISSION INJECTION ---
# Grant legacy location permissions (often required for discovery on apps targeting older SDKs)
adb shell pm grant com.getchannels.dvr.app android.permission.ACCESS_FINE_LOCATION
adb shell pm grant com.getchannels.dvr.app android.permission.ACCESS_COARSE_LOCATION
# Attempt to grant the modern discovery gate (Note: may fail if not in the original Manifest)
adb shell pm grant com.getchannels.dvr.app android.permission.NEARBY_WIFI_DEVICES
# Manually enable the Multicast Lock (Operation 21) so the app can "hear" mDNS traffic
adb shell appops set com.getchannels.dvr.app 21 allow
# --- STEP 3: BYPASS RESTRICTED SETTINGS (PIXEL-SPECIFIC) ---
# Manually allow 'Restricted Settings' to bypass greyed-out menus and the missing 3-dot menu
adb shell appops set com.getchannels.dvr.app ACCESS_RESTRICTED_SETTINGS allow
# Enable Nearby Devices interaction at the AppOp level (Operation 116)
adb shell appops set com.getchannels.dvr.app 116 allow
# --- STEP 4: FIREWALL & STANDBY OVERRIDES ---
# Replace [UID] with the number found in Step 1
# Add the app to the network policy background-allow whitelist
adb shell cmd netpolicy add restrict-background-whitelist [UID]
# Prevent the OS from throttling the app by forcing it into the 'Active' standby bucket
adb shell am set-standby-bucket com.getchannels.dvr.app active
# Add the app to the Device Idle (Doze) whitelist to keep network sockets alive in background
adb shell dumpsys deviceidle whitelist +com.getchannels.dvr.app
# --- STEP 5: DIAGNOSTIC VERIFICATION ---
# Verify if 'effective' state has changed from NONE to ALLOWED
adb shell dumpsys netpolicy | grep "[UID]"
# Check if the OS has successfully registered a Multicast Handler for the app
adb shell dumpsys connectivity | grep -A 10 "mMulticastHandlers"
# Monitor logs for Permission Denied or Socket EACCES errors in real-time
adb logcat -v time | grep -iE "channels|NsdManager|mDNS|SSDP|NEARBY|Permission|Socket|DENIED"
You may need to get an Apple Phone or Tablet for your super remote. The developers push us to use their preferred Apple devices. So far, I haven't succumbed to the pressure. But I may see if I can get an old Apple Tablet just for testing with Channels. The Apple TV is not adequate for my needs, so I can't go that route.
Ha ha, the infamous Tim Cook response: "Just tell your mother to buy an iPhone [etc.]." If Channels is going to hitch their wagon to (mainly) Apple TV, then they are intrepid souls indeed. Pilfering content that users have already paid for elsewhere (e.g., MLB games) for "Apple TV Exclusives" is not going to get the market share job done for Apple.
I am already drowning in Apple products due to (gender-specific) family members. I basically deprecated Apple 2 years ago as they do not meet my needs, they are too locked down for my use cases. Got an Apple bug or lousy implementation? Too bad (and look forward to it only getting worse).
Google tip toed into that "walled garden" direction by suggesting it was going to ban sideloading (which would have also snagged ADB installs). Luckily, that trial balloon was shot down pretty quickly.
For now.