Solved-Ish: Screen Mirroring/Casting Requires Location Permissions

TL;DR: Strange technical quirk rather than datamining techbro shenanigans (okay, only a little techbro shenanigans). This is “Miracast” under the hood, which (sometimes) requires scanning for and connecting to a dummy WiFi Access Point to make a direct connection, and baddies¹ can use access to your nearby APs for location tracking, so this scan is gated behind location permissions.

Funny story, I just got back from a fishing trip with the kids and we wanted to show Mrs. (who couldn’t go due to work) pictures of it from my phone on the big TV. “But Tiiiim!”, she cried, “everytime you try to do something like this it doesn’t work and takes an hour of rebooting and fiddling with things.”

I protested: “It’s 2026! It’s screen sharing! It’s between un-hacked commercial devices that natively support this as a bullet-point sales feature!” Yeah, so trying to cast to the TV didn’t work, and I ended up running downstairs to my desktop to plug in a cable like a savage to transfer the photos to my janky Raspberry Pi media center setup over Samba and stream them over Jellyfin. Then (after Mrs. went to bed), spent an hour debugging why screen mirroring (“casting”…) to the Roku TV no longer works².

While digging into that, a discovery…

Yes, that is a real (squished for space) screenshot; the phone (OnePlus / OxygenOS) is blocking me from screencasting (“Display Mirroring” by any other name, we’ll get to that) to my own TV in my own living room, a handful of feet away, on the same wireless network until I enable location permissions.

As a rule, I don’t give platform to shenanigans like this. Looks like an open-and-shut case of permissions creep and enshittification land-grab, right? Strangely though, when selecting the long-forgotten Chromecast as a screen mirroring destination, it just works (not really, it crashes after a bit or when the first session disconnects, but it connects without asking where I live first). Why does only casting to a specific device demand location access? So the plot has thickened and I dug in a bit. Web searching this produced no direct hits (even with the usual “+reddit”) because 2026 and web search, but here is what I ultimately learned.

First: What’s all this ‘Casting’ stuff, anyway?

Insert fishing trip joke here. In short, the industry, especially where mobile devices are concerned, has developed a bewildering array of competing protocols and terminology for sharing screen content, which all go by a weird mix of overlapping and vendor-proprietary names.

So first off, there are at least four mainstream competing under-the-hood protocols for the act of sending screen content to another device that might be labeled as “Casting”³ and use identical glyphs and logos. These are:

• “Casting” (Chromecast protocol, formally Google Cast) is a proprietary protocol developed by Google for sending audiovisual content to another device. Typically a specific piece of content or view, window, etc., is forwarded by an application implementing this protocol, not the entire device screen.
• “Casting” (various oddball app-specific methods) is a means of sending metadata from a specific app on one device to another instance of that same app running on the other device. For example, “Cast”ing a video from the YouTube app basically just sends the URL to a copy of the YouTube app (if one exists and is installed) on the other device. If the same app isn’t installed in both places, or isn’t available because competing app stores, or the versions aren’t adequately matched, or they can’t find each other, or the vendor is mad at you, etc., this doesn’t work, and of course this mechanism is app-specific and has to be re-invented for every app.
• “Casting”, aka Screen Mirroring. This is actually the Miracast protocol, and sends audiovisual content, typically the full screen. According to the official Roku documentation for this feature on their devices, “Common terms for screen mirroring include:
  • Smart View
  • Quick Connect
  • SmartShare
  • AllShare Cast
  • Wireless display
  • Display mirroring
  • HTC Connect
  • Screen casting
  • Cast”
  • According to Wikipedia, it could also-also be called easy mirroring (Panasonic) or Connect (Windows 10)
• Apple AirPlay, A proprietary Apple thing that sends A/V content to the remote device, kind of like the Chromecast protocol. At least it has its own well-defined name that’s less likely to be labeled “casting”.

So, the “Casting” in question here is really the Miracast protocol for my case (Roku devices don’t support the Chromecast protocol). A fun sidenote, Miracast, an industry standard governed by the WiFi Alliance, is supported by basically all Android smartphones except Google-branded ones (e.g. Nexus and Pixel). Google rather pointedly removed support for it from Android beginning in v6.0 to push its proprietary Chromecast protocol instead, and pretty much all other device vendors manually add it back in their own Android forks.

The Miracast and Location Connection

Despite all the documentation and admonitions to “ensure both devices are on the same network”, Miracast typically uses Wi-Fi Direct, bypassing your network entirely and creating its own WiFi Access Point (SoftAP) on one device to establish a direct connection. Unfortunately, it’s well-known that WiFi access points tend to hang around a long time without moving, giving rise to myriad WiFi location databases that can be used to pinpoint a user by scanning for nearby APs. Due to this, since Wi-Fi Direct relies on scanning for and connecting to these newly-created SoftAPs, Android (at minimum) requires granting location permissions to scan for WiFi devices (and Bluetooth, for the same reason). A quirk is that there is also a “Miracast over Infrastructure” mode, which only some implementations support, that works like your more traditional discovery protocols sending and receiving announcement packets over an existing network. This may explain why not all Miracast destinations require granting location permissions. As for why devices are discovered without location permissions (AP scanning), but require it to connect, don’t ask me. A quick scan of the Miracast spec suggests that if the device is already connected to a network, it will send more traditional discovery info on that network via mDNS, even though the Wi-Fi Direct mechanism ultimately expects you to bypass it for a direct connection (via scan) to the SoftAP.

Unfortunately – and here is where the techbro shenanigans come in – this falls under Android’s fine-grained location permission, and enabling “Location” is all-or-nothing. Seemingly by design, there is no distinction between acknowledging the technical implementation could be misused for location tracking, and granting consent to actively do so. Under Android (at least), there is no granularity to grant AP scanning at the app or system level without also granting e.g. GPS access, nor easily bound it to that specific interaction. The low-resistance path is for the user to knuckle under and broadly grant “location” permission to the app, which, even if the app developer is honest, may be misused by someone down the chain, this misuse ranging from “merely” creepy ad-targeting to one’s location history being resold to repressive governments. Likewise, enabling “location” at the system level is taken by Google as a greenlight to actively collect it in all available forms, with all of the same aforementioned issues, not merely enable technical features that could be used to do so.

So, I kind-of get it, in one sense they are warning you that we can’t have nice things – this feature inherently comes with a data collection risk and some ne’er-do-well app could use it to hoover information⁴ – but in another sense they’ve solved the “have to sleep with your boss if you want that promotion” problem by just pressuring you to sign a consent waiver first, with a clause saying that they get to watch too.

1. “Baddies” being defined as not-the-industry-leaders by the industry leaders (including ones that rhyme with Foogle), who are already doing this all the time, including creating that database itself to resell access to those non-industry-leading baddies. ↩︎
2. For my specific case, the problem was mainly lack of clarity over which underlying protocols were/weren’t supported by the app-specific ‘Cast’ button I was trying to use (app assumed Chromecast protocol, TV “cast” feature only supports Miracast), coupled with the fallback Chromecast (which does, of course, support Chromecast protocol) not appearing due to being crashed, thus making it look like a broader network discovery problem. More and more, I find that my janky homerolled solutions are actually becoming more reliable than commercially-supported cross-vendor ones, if only because all the moving parts are actually visible and they don’t depend on the benevolence of competitors who are actively trying to kneecap each other. ↩︎
3. Plus about several thousand others for streaming screen or A/V content that, for whatever reason, are not called “casting” or commonly baked into mobile devices. ↩︎
4. In this case, why do individual apps have to separately implement the scanning functionality and have access to the resulting AP data? I.e., why is this industry-standard protocol and discovery not handled by the device OS itself? (Oh, wait, see note above about Google ripping it out of Android OS since it competes with Google Cast.) ↩︎