Android-Dex: a Samsung DeX alternative that wraps scrcpy in a Flutter desktop client

What the repository actually contains, and what it does not

The first thing to sort out is what you are looking at on GitHub. The README describes a free, closed-source desktop application for Windows, Linux and macOS, and the file tree bears that out in an odd way: what sits in the repository is a web page (`index.html`, `style.css`, a `web/` directory, a `Data/` folder of screenshots) plus a `doc/` directory of design notes. GitHub reports the repository language as HTML for exactly that reason. There is no Flutter source, no Gradle project and no Kotlin companion service in the tree, so nothing here can be built from a clone.

That split is worth being blunt about, because it changes what you can evaluate. You can read the architecture, you can download a binary per platform from the release table, and you cannot audit the code or patch it. The README is candid about this, listing ADB, scrcpy, Flutter and Kotlin as the foundations it stands on rather than claiming an original implementation, and thanking rom1v for contributions in the ADB and scrcpy ecosystem that informed the design.

The repository has 2,661 stars and 202 forks, and the last push was on 2026-09-14. The most recent release, Android-Dex-v.1.3, followed a day later on 2026-09-15, which is the pattern of a project that ships when it ships rather than on a calendar.

Install path: three archives, and an architecture caveat

There is no package manager route and no build step. The README's download table points at three release assets, one zip per operating system:

https://github.com/Shrey113/Android-Dex/releases/latest/download/Android_Dex_Windows.zip
https://github.com/Shrey113/Android-Dex/releases/latest/download/Android_Dex_Linux.zip
https://github.com/Shrey113/Android-Dex/releases/latest/download/Android_Dex_macOS.zip

One detail does not line up neatly with that table. The v1.2 release notes mention that the builds now carry `_x64` and `_ARM64` in their names and that those are for testing only, while the README's download links use plain platform names with no architecture suffix. Both facts come from the project itself, and the practical answer is to look at the asset list on the release page rather than trusting the README table, since an Apple Silicon Mac and an x86 Windows box are different downloads and the table does not say which one you get.

Beyond the archive, the runtime prerequisites are ordinary Android ones. You need platform tools on the host for ADB, and the phone needs USB debugging enabled or wireless debugging paired. The README frames wireless pairing as part of ADB's own feature set rather than something this project reimplements.

Windowed apps, mirroring and the shortcuts that matter

The core claim is that Android apps run in resizable desktop-style windows alongside screen mirroring, per-app audio streaming and notification handling. If that holds, the difference from plain scrcpy is the desktop shell: scrcpy gives you one mirrored surface with scaling options, while this client is arranging several app surfaces at once with a taskbar, a recent panel and a media center. The v1.2 notes describe a new file manager inside the app, screen recording reachable from Quick Settings, a screenshot shortcut for the current app, window or whole screen, and multi-finger trackpad gestures that supersede an earlier touch pad.

The keyboard map is short enough to learn in a minute:

Ctrl + G
Ctrl + F
Esc
Ctrl + Alt + Up / Down
Ctrl + Alt + Left / Right

Those are the whole binding surface: `Ctrl + G` toggles game controls for the current app, `Ctrl + F` and `Esc` handle fullscreen, `Ctrl + Alt + Up` and `Down` show and hide the client, and `Ctrl + Alt + Left` and `Right` switch between connected devices or open the device switcher. The v1.0.1 release notes record one of these as an actual bug, with `Ctrl + G` failing to open the game bar, which tells you the game layer is the part that has needed the most iteration.

Windows are managed as tasks rather than as a static grid. Release 1.2 added a recent panel backed by a live-updating backend, because items were previously sticking at a stale state, and release 1.3 fixed a case where the app would get stuck, referenced as issue 103.

The keymapper and its emulator detection claim

The Gaming Mode section is the most specific marketing in the README, and it deserves careful reading. It claims games run on physical Android hardware with touch events delivered through low-level native protocols, so anti-cheat sees a genuine phone rather than an emulator, and the claim is that this grants access to native mobile lobbies. The listed controls cover tap spots with turbo fire bound to keys or mouse clicks, an eight-direction joystick with deadzone and sprint zone tuning, cursor lock with gyroscope emulation for aiming, a right-click aim or ADS binding, directional swipe triggers, multi-step macro sequences, and a profile manager that stores per-game layouts in a local database.

What is verifiable from the outside is the feature list, not the anti-cheat outcome. Nothing in the repository lets you check which protocol path is used for injection, and the code that would answer it is not published. A reader deciding whether to trust this should treat the lobby claim as a statement about how the tool is marketed, and test the mapping layer on a game they do not care about first.

One design decision does explain the direction of travel. Using scrcpy's video pipeline means the host is decoding a hardware-encoded stream, which is why the release notes are full of MediaCodec and encoder fixes.

Encoder crashes, and what the v1.3 notes reveal about the pipeline

Release Android-Dex-v.1.3 is a bug fix release and it is unusually specific about where things broke. Three separate issues are called out: the app getting stuck, which the notes attribute to a change that now checks only release-safe properties such as `context.mounted` and `ro.hasSize` and skips active scrcpy texture windows; phone full-screen gestures stopping (issue 132); and an oversized encoder crash presenting as a black screen (issue 133). The MediaCodec resize crash was traced to an aspect-ratio multiplier that was inflating dimensions, with a short wide window turning into a width of 4185 pixels.

That detail is useful for anyone reasoning about the class of problem rather than this project in particular. A desktop client that resizes a video surface aggressively is pushing a hardware encoder outside the range it was tuned for, and the fixes are all about clamping what you send rather than about the client itself.

The same release added `_MACHINE`, `ARCH` and `ARCH_FLUTTER` constants at the top of the config file, referenced against issues 142 and 135, which lines up with the architecture split mentioned in the 1.2 notes. Release 1.0.1 is the point where Windows, Linux and macOS support arrived together.

The doc directory is the real technical content

Seven design documents are linked from the README and they map onto the parts of the system that are hardest to reverse:

doc/ARCHITECTURE.md
doc/BOOT_FLOW.md
doc/RECONNECTION.md
doc/DATA_MODEL.md
doc/ERROR_HANDLING.md
doc/MODULES.md
doc/DEVICE_MANAGER.md

Naming them tells you a lot about the project's centre of gravity. A boot and handshake document means the client and the on-device companion service negotiate before anything is displayed, and a reconnection and auto-healing guide means the design assumes the link drops mid-session, which is the normal case on wireless ADB. Error handling and diagnostics getting their own reference suggests the failure surface was large enough to need a taxonomy rather than a log line.

The honest summary is that the published documentation covers architecture and behaviour well and covers installation thinly. Once you have a binary, the remaining unknowns are the ones no document can settle from outside: latency on your particular network, frame pacing on your particular GPU, and whether profile storage migrates cleanly between the architecture variants. Those are questions for a weekend with a spare phone, not for the docs.

Editorial conclusion

Android-Dex is a good fit if you want DeX style app windows and a real keymapper on a device Samsung never intended to have them, and you are willing to install a closed-source build that GitHub reports as mostly HTML because the repository holds the project page rather than the program. What the published docs settle clearly is the intended architecture, the boot handshake and the error taxonomy, which makes it a fair bet for someone who wants to understand how this kind of client is put together. What they do not settle is whether the wireless path is as reliable as the USB one on your network, or how profiles migrate between the x64 and ARM64 builds. Start with the USB path and the Architecture and Boot Flow documents, then check whether the release notes still mention encoder stalls before you commit to it as a daily driver.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Shrey113/Android-Dex on GitHub