Second plugin. This one puts your Android phone on your desktop: mirrored screen, mouse and keyboard control, no root, no Samsung account, no paid tier, no separate app installed on the phone begging for permissions it doesn’t need.
Under the hood it’s scrcpy doing the actual mirroring, because scrcpy is excellent and rewriting it would be idiotic. KDE Connect is optional on top for battery status and Ring. What I built is the part that makes those two things pleasant to live with instead of a pile of terminal commands you look up every single time.
Currently sitting in the Omarchy marketplace queue waiting on security review, which feels appropriate given how much of this post is about security decisions.
The thing that took the most thought
Getting a phone mirrored is not hard. Getting a phone mirrored is scrcpy and about four minutes of reading. The hard part is everything around it, and specifically one question that came up over and over in different costumes: when is this software allowed to guess?
Take phone identity. Multiple connections can point at the same physical phone. USB and Wi-Fi at the same time, IPv4 and IPv6, an address that changed when your router handed out a new lease. You want those grouped into one card, obviously, because they’re one phone.
But grouping is a claim. If I merge two connections into one card, I’m asserting they’re the same device, and if I’m wrong your input goes somewhere you didn’t intend. So merging only happens on hardware identity that Android actually reports. Matching model names never merges anything. Matching nicknames never merges anything. Two Pixels with the same nickname are two phones until the hardware says otherwise, because “they’re both called Pixel” is a coincidence, not evidence.
If Android refuses the identity query and discovery can’t work it out, the connection stays separate as an unresolved entry rather than getting quietly filed under whichever phone looks closest. An unmerged duplicate is a minor annoyance. A wrong merge sends your keystrokes to the wrong device.
Reconnecting without being creepy about it
Remembered phones reconnect automatically when discovery advertises the same identity, even if the address and port both changed. That’s genuinely convenient and it’s the behavior you want.
What it does not do is automatically pair with phones it’s never seen. It does not start a mirror session on its own. Retries are capped at once per address every 30 seconds, and you can turn the whole thing off. After a successful pairing there’s a ten minute window where discovery can finish the connection, and then it stops.
The difference matters. Reconnecting to a phone you already explicitly authorized is completing something you started. Pairing with an unknown phone because it happened to show up on the network is a decision nobody asked it to make.
Same principle as the GPU selection in my last plugin: auto mode gets to be clever, explicit choices get respected exactly as made.
Wake is not unlock
There’s a Wake/unlock button for when the phone’s asleep. It sends Android’s wake command and asks Android to show its normal unlock prompt. Then it stops and you unlock the phone yourself.
It does not submit credentials. It does not bypass a secure lock. It cannot, and it shouldn’t be able to, and I’m not interested in building the version that tries. Lock screens and capture-protected apps keep enforcing their restrictions through the mirror exactly as they should, and if that’s inconvenient in some specific app, good. That’s the lock working.
What it does not do, deliberately
No telemetry. No advertising. No cloud relay. No automatic update check. No crash upload. Nothing phones home, ever.
Runtime phone endpoints are restricted to private local-network addresses. There’s no support for pointing it at a public Internet endpoint or overriding the remote ADB server, because a phone-mirroring tool that can be aimed at an arbitrary remote host is a substantially different and worse thing than one that can only talk to your own LAN.
Automatic clipboard sharing is off. You paste with an explicit keystroke or it doesn’t happen. Pairing codes go through standard input, get cleared from the panel, and never touch disk or appear in a process command line where anything reading the process list could scoop them up.
Nothing gets installed just because you opened the panel. There are Install buttons for missing tools, and they do exactly nothing until clicked.
And it’s honest about what authorization actually means: ADB pairing gives this computer debugging access to your phone, disabling the plugin does not revoke that, and if you stop trusting a machine you need to forget it in Android’s own settings. That’s in the README rather than buried, because someone who installs this should understand what they just handed out.
The bit I’m quietly pleased with
The four-step connect guide. Desktop, Phone, Pair, Ready. Every one of those steps can fail in its own specific way and each failure gets its own specific message instead of a generic “could not connect” that leaves you guessing which of five things went wrong.
Wireless pairing on Android has a genuine trap in it: the pairing port and the connection port are different numbers, and nothing about the Android UI makes that obvious. People get it wrong constantly and then have no idea why nothing works. So the plugin calls it out directly, in bold, right where you’d hit it.
That’s not clever engineering. It’s just having actually used the thing and noticed where I personally got stuck.
omarchy plugin add https://github.com/onelegdave/omadroid --enable
Waiting on security review for the marketplace. In the meantime it installs fine straight from the repo, and every command it can run and every network endpoint it can reach is inventoried in SECURITY.md if you’d rather check before trusting it. Which, for something that gets debugging access to your phone, you probably should.