Open-source project
Zfinix/another avatar
Zfinix/another

Another: a Tauri desktop front end for scrcpy on Android

A desktop app for mirroring and controlling Android devices over USB. Built with Tauri, React, and Rust.

829 stars78 forksTypeScriptMIT

At a glance

What is it?
Another is a MIT-licensed Tauri application that mirrors and controls Android devices over USB by driving a bundled scrcpy-server, and it also exposes the device through an MCP server on port 7070. The wrapper is polished, but the platform support table and the release history are where the real limits sit.
Who is it for?
Another is worth adopting on macOS for a developer who wants scrcpy-style mirroring with macros, a command bar and agent control over the same device, and it is the wrong choice for a Linux or Windows fleet because both are marked experimental. Verify first that your device exposes ADB or WiFi debugging, that your Android version is 11 or newer if you need audio forwarding, and that the 0.4.x release you install matches the scrcpy-server v2.7 build the app expects.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 18 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Another wraps a bundled scrcpy-server instead of reimplementing streaming

The streaming pipeline is not written from scratch. The project states that it uses a bundled scrcpy-server to stream video from the device and send control inputs back, and the tech stack line names ADB plus scrcpy-server v2.7 as the device communication layer. So the video codec path, the control protocol and the device handshake come from the Genymobile project, and Another sits on top as the user interface and the automation layer.

That division explains several of the features. Real-time screen mirroring runs through H.264 and H.265 decoding rather than a custom pipeline, and touch, keyboard, scroll and navigation input forwarding are the input side of the same connection. Adaptive video bitrate, configurable resolution, FPS, bitrate and codec, and the macOS-style shortcut set for volume, home, back, recents and power are all controls layered over that transport.

It also explains the shape of the repository. Cargo.toml declares a workspace with members src-tauri, crates/another-core and crates/another-mcp, so the core device logic and the MCP server live in their own crates rather than inside the Tauri shell. The frontend is a separate Vite and React app under src, with package.json holding the JavaScript dependencies, the eslint setup and the tauri scripts. The Rust and TypeScript sides are genuinely split, and the interesting engineering sits in the two crates.

Building the desktop shell with bun, Vite and Tauri

Development needs Rust, Node.js and Bun installed, plus an Android device reachable through ADB with USB debugging enabled, or through WiFi debugging. Once the toolchain is in place, the loop is two commands:

sh
bun install
bun tauri dev

The first installs the JavaScript dependencies, the second starts Vite and the Tauri shell together. On Ubuntu or Debian, including WSL, the project asks for the WebKitGTK, ALSA and pkg-config development packages first:

sh
sudo apt update
sudo apt install libwebkit2gtk-4.1-dev  pkg-config libasound2-dev

Those two packages are the part that trips people up on Linux, because the Tauri window needs the WebKitGTK stack and the audio path needs ALSA headers. A production bundle comes from the same toolchain:

sh
bun tauri build

For macOS specifically, package.json carries dedicated scripts. The build script runs tsc and vite build, and there is a build:dmg script that calls tauri build with the dmg bundle target, plus a publish:dmg script that chains the dmg build with a gh release upload of the files in src-tauri/target/release/bundle/dmg. Note that the npm package name is tauri-app and it is marked private, so this manifest is a build harness rather than a published library.

The MCP server on port 7070 gives an agent the device

The most distinctive feature is the MCP server, which starts automatically with the application on port 7070 and can be toggled on and off in Settings. A client that speaks HTTP transport points at the local endpoint:

json
{
  "mcpServers": {
    "another": {
      "type": "http",
      "url": "http://localhost:7070/mcp"
    }
  }
}

Tools that only speak stdio can spawn the bundled binary instead, and the path to the scrcpy-server build is passed as an argument:

json
{
  "mcpServers": {
    "another": {
      "command": "another-mcp",
      "args": ["--scrcpy-server", "/path/to/scrcpy-server-v2.7"]
    }
  }
}

The tool surface is wide enough to be a device remote control: list, connect and disconnect devices, take a screenshot, press home, back, recents, power or volume, send text, send a touch or a scroll at coordinates, swipe between two points, run an adb shell command, open a URL, launch an app by package name, enable WiFi debugging, connect or disconnect a WiFi device, fetch the device WiFi IP address, and record, stop, play, list or delete a macro. An AI agent skill is distributed separately, with a npx command that installs it from the repository.

The security question is worth naming plainly. The endpoint listens on localhost and an agent can run adb shell commands on a connected device, so any process able to reach that port inherits the full tool list. The documentation does not describe an authentication mechanism, and the toggle in Settings is the only control it mentions.

Macros, WiFi debugging and the Android 11 audio floor

Macros are the feature that separates Another from a plain scrcpy window. The app can record a sequence of device interactions, replay it, and import, export and rename those macros. The MCP tools expose the same lifecycle, with another_macro_record, another_macro_stop, another_macro_play, another_macro_list and another_macro_delete, which means a macro can be captured from the UI or driven by an agent.

WiFi mirroring is advertised as a one-click move off the cable, and the tool list backs it with another_wifi_enable, another_wifi_connect, another_wifi_disconnect and another_get_device_ip. The catch is that wireless control depends on the device having WiFi debugging enabled, which is a device-side setting the user has to reach first, not something the app can arrange on its own.

Device audio forwarding carries an explicit floor of Android 11 and later. Screen recording is written to .webm, and screenshots are captured from the live stream rather than from a separate device call. Themes, device nicknames, automatic detection via ADB and a command bar with a shortcut for every action are the smaller conveniences, and they are what make the app pleasant to leave open on a second screen.

For anyone automating repeated device tasks, the macro system is the reason to choose this wrapper rather than the upstream scrcpy command line, and the version floor on audio is the first thing to check against a fleet of older devices.

The platform table marks Linux and Windows as experimental

The support table is short and worth quoting accurately. macOS is listed as supported. Linux is listed as experimental. Windows is listed as experimental. The release table still offers artifacts for all three: a .dmg for macOS on both Apple Silicon and Intel, a .deb / .AppImage for Linux, and a .msi / .exe for Windows.

The gap between an available installer and experimental support is the kind of thing that only shows up in support requests. On Linux, the WebKitGTK and ALSA development packages are listed for development, which tells you the desktop toolkit path is real but still being worked on. On Windows, the keyboard table gives a clear hint about the current state: the shortcuts are written with the command symbol, and a note says that on Windows and Linux you use Ctrl instead. macOS-first conventions leaking into two platforms that are not finished is a reasonable summary of the project state.

The same pattern shows in the release history. Three releases landed within a few hours of each other, v0.4.2 on 2026-10-05, v0.4.3 and v0.4.4 on 2026-10-06, with the last push to the repository on 2026-10-06. Version 0.4.4 is a pre-1.0 number, and a project shipping several builds in a day is iterating on its own bug list rather than maintaining a stable contract.

Where Another is the wrong choice

There are clear cases where this app does not fit. It is an Android tool. The device communication layer is ADB plus scrcpy-server, and no iOS path appears anywhere in the documentation, so a team that needs to mirror iPhones has to look elsewhere.

It is also the wrong tool when you want a command line. The upstream scrcpy project that Another bundles already provides a terminal interface with the same streaming and input capabilities, and using it directly removes the Tauri shell, the MCP server and the Mac platform dependency from the picture. Another earns its keep when you want the UI, the macros, the command bar and the agent surface, and adds nothing when the goal is a scriptable mirroring loop in CI.

Third, a fleet of mixed devices is a poor fit. Audio forwarding stops at Android 11, wireless control requires WiFi debugging to be turned on per device, and the two platforms that are not macOS are flagged experimental. Macros also encode a sequence of screen coordinates, so they are tied to a screen layout and a device state, which makes them brittle across different resolutions or app versions.

Finally, the MCP server widens the blast radius of the app. Exposing shell execution and screen input to any local client that can reach port 7070 is a different trust model from a manual mirroring session, and the documentation offers no description of authentication or scoping.

MIT licence, pre-1.0 versioning and a fast release rhythm

Another is released under the MIT licence, with a LICENSE file at the top of the repository, which is the most permissive end of the usual choices for a desktop application. Vendoring the scrcpy-server binary and the scrcpy-server v2.7 path in the stdio configuration means your distribution choices around that binary matter as well, and the project does not spell out how it expects forks to handle it.

The release history is unusually compressed. v0.4.2 was published on 2026-10-05, v0.4.3 on 2026-10-06 and v0.4.4 on 2026-10-06, and the repository's last push was on 2026-10-06. The current package.json version reads 0.4.4, which matches the newest release. The published download links all point at the releases/latest redirect rather than at pinned artifacts, so every install tracks the newest build and the exact version you validated is not preserved for you.

For a team that wants to adopt this, the practical consequence is that you are adopting a moving target. If you need a pinned build, download the .dmg, .deb / .AppImage or .msi / .exe for a specific tag and check that the bundled scrcpy-server version still matches the v2.7 path the stdio MCP configuration expects. The features are already there, macros, agent tools and command bar. The maturity signals are not.

Editorial conclusion

Another is worth adopting on macOS for a developer who wants scrcpy-style mirroring with macros, a command bar and agent control over the same device, and it is the wrong choice for a Linux or Windows fleet because both are marked experimental. Verify first that your device exposes ADB or WiFi debugging, that your Android version is 11 or newer if you need audio forwarding, and that the 0.4.x release you install matches the scrcpy-server v2.7 build the app expects.

Frequently asked questions

How do I connect an Android device to Another?

Enable USB debugging on the device and connect it over USB, or turn on WiFi debugging and connect by IP. Device detection is automatic via ADB, and the app bundles scrcpy-server v2.7 to stream the video and send control inputs back to the device.

Can an AI agent control my Android device through Another?

Yes, through the MCP server that starts automatically with the app on port 7070 and can be toggled in Settings. The tool list covers device listing and connection, screenshots, taps, swipes, text entry, adb shell commands, app launching and macro record and replay, reachable over the http://localhost:7070/mcp endpoint or through the another-mcp stdio command.

Which platforms does Another support?

The support table lists macOS as supported, and Linux and Windows as experimental. Release artifacts exist for all three, a .dmg for macOS on Apple Silicon and Intel, a .deb / .AppImage for Linux, and a .msi / .exe for Windows.

Does Another support audio forwarding from the device?

Device audio forwarding is listed as supported on Android 11 and later. Screen recording is saved as .webm, and the app also has a shortcut to mute and unmute the forwarded audio.

Official sources

  1. Issues
  2. License: MIT
  3. README
  4. Releases
  5. Zfinix/another on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/zfinix-another.svg)](https://hysenlabs.com/projects/zfinix-another)

Was this useful?