HybridFileXfer (多轨快传): Moving Phone Files to a PC Over USB and WiFi at the Same Time

What HybridFileXfer Solves, and Who It Is For

A single WiFi link or a single USB link caps out. The README states the project's intent plainly: use every I/O channel the phone can expose at once. The headline examples in the README are USB2.0 plus WiFi6 on a gigabit port reaching 150MB/s (40 plus 110MB/s), and USB2.0 plus WiFi6 5GHz at 160MHz plus WiFi6 2.4GHz at 40MHz reaching over 200MB/s.

The target user is someone with a phone full of large files and a computer on the same LAN. The README's own framing is about draining the phone's I/O, not about syncing or backup. There is a desktop client written in Java, an Android app, and a launcher directory in the repository. The interface on the phone is a two-pane file manager, described in the README as modeled on MT Manager: the left pane is phone storage, the right pane is computer storage, and a transfer goes from one side to the other.

This is not a general file-sharing protocol. It is a point-to-point transfer tool with a specific topology: one phone, one computer, one or more network paths between them. If your files already live in a cloud account or a NAS, the tool adds a hop rather than removing one.

How the Multi-Channel Transfer Actually Works

The README describes the mechanism in its principles section. On the sending side there is one file-reading thread and several network-sending threads. The reader pulls the file into 1MB blocks and pushes each block onto a queue. The sending threads take blocks off that queue and write them to the network.

The receiving side is where the design gets interesting. Each receiving thread has its own queue. Received blocks are appended to the tail of the relevant queue, and a single file-writing thread looks at the head index of every queue and writes the lowest one next. That ordering step is what lets blocks arriving out of order over different interfaces still land in the file in the right sequence.

Above the data channels sits a control channel. The README separates the two roles: the control channel handles notifications about sending or receiving files, listing folders, and creating folders, while the transfer channels carry the file bytes. When the desktop client connects, it first reaches the control channel, then asks that channel for the network interface information the phone has selected, and then connects to each of those interfaces as a separate transfer channel. The documentation states that the transfer file button becomes active only after all selected routes have connected.

Installing the Desktop Client and Making a First Transfer

The repository lists HybridFileXfer-Android, HybridFileXfer-PC, and HybridFileXferLauncher as top-level directories, and the README points readers to the corresponding desktop client download. The PC client is a jar, so the README notes that Java is required and links to the JDK 17 archive page, describing the process as similar to installing Java for Minecraft.

On the phone, you pick a mode and the network cards you want to use, then start the server. The README's mode list is normal, ROOT, and ADB, with Shizuku used to start the IO service. ROOT has the highest permissions; ADB is described as slightly higher than normal, enough to reach an external SD card. The README is explicit that the ~/Android/data/ directory requires ROOT mode and that ADB cannot reach it.

Once the phone shows a waiting state, run the client. The mandatory arguments are -c for the connection method, -s for a USB device ID, and -d for the receiving directory on the computer, which defaults to /. The README gives these examples:

java -jar HybridFileXfer.jar -c adb
java -jar HybridFileXfer.jar -c adb -s abcd1234
java -jar HybridFileXfer.jar -c adb -d C:\Users\Administrator\Desktop\
java -jar HybridFileXfer.jar -c 192.168.1.2

With -c adb, the client uses adb forward tcp:<port> tcp:<port> to push the phone's port to 127.0.0.1 on the computer, so USB carries network traffic. The README's sample output shows the port forward succeeding on 5740 and then each card connecting in turn, ending with a line saying all transfer channels are connected. If the computer has not been authorized for USB debugging, the README says to tap allow on the phone.

On Arch Linux there is an AUR package, and the README asks that AUR packaging issues go to the AUR comments rather than the project issue tracker:

yay -S hybridfilexfer-git
paru -S hybridfilexfer-git

After installation the command to launch the desktop side is HybridFileXfer. Linux support is documented as x86 only for the bundled adb, since adb is architecture-dependent even though Java is not; the README suggests supplying an adb binary for ARM, RISC-V, or Loongson, or using USB tethering instead.

The Missing Progress Bar Is a Deliberate Trade-off

The README has a section titled about the progress bar, and the answer is that there is no progress bar. The reasoning given is that calculating progress is expensive, especially with many small files. The README cites a screenshot folder where the calculation alone took one third of the total time, and references fastcopy as the precedent for skipping it.

That is a real limitation, not a cosmetic one. A 200MB/s transfer of a single large file gives you no on-screen signal of how far along it is. For a folder of thousands of small files, the transfer may be slow for reasons that have nothing to do with the network, and the UI will not tell you which phase you are in. If your workflow depends on an ETA, this tool will frustrate you.

The README also warns against selecting interfaces that cannot carry LAN traffic. The list of things that show up as network cards includes VPN TUN interfaces, with an explicit note not to select them, and Bluetooth network sharing, which is listed as not recommended. Cellular is filtered out entirely, with a note that changing the source is required to bring it back. The README's instruction is to choose interfaces that can do LAN transfer with the computer, which means the multi-channel speedup only exists when the topology supports it.

Phone-to-Phone Transfer and the PC-in-the-Middle Workaround

The app has a built-in transfer feature reachable from the top right of the main screen, labeled connect to phone server. The README says to make sure the peer phone's selected card IPs are reachable, over the same WiFi LAN or a hotspot, and to pick any card IP for the control channel. It also warns not to check the USB_ADB card when not using ADB forwarding.

Using USB between two phones is where the README gets candid. The first option, an OTG or double Type-C cable, has two problems: running ADB over USB on the phone side needs ROOT, and USB tethering is not usable on Android phones for this. The documented solution is to plug both phones into a computer and let the computer forward. The server phone's port is forwarded to the computer with adb forward, and then the computer's port is forwarded back to the client phone with adb reverse. The repository includes USB-forward.bat and a Chinese-named variant, USB-forward_中文.bat, to run this. After forwarding, the USB_ADB card can be checked, and the control channel may optionally use the local address 127.0.0.1.

This is a workable design, but it means the two-phone case is not actually a two-phone case. You need a PC with adb and the script, and you need both phones authorized. The README does not document what happens when the forwarding script fails partway or how to roll back a half-applied forward.

Where HybridFileXfer Is the Wrong Tool

The ADB path assumes USB debugging is available and that you can authorize the computer. The README offers USB tethering as a substitute if you cannot use ADB, which changes the topology: the phone shares its connection and the computer joins that network. That is a different setup from the one the speed examples describe.

Directory access is another boundary. The README states that ~/Android/data/ requires ROOT mode and that ADB cannot reach it. If your files live inside Android/data on Android 11 or later, the normal and ADB modes will not see them. The README's response to this constraint is blunt, telling users to email Google's Android department rather than the project.

Platform coverage is uneven. Linux is supported for x86 with the bundled adb, and the README says the author has not tried macOS, though Java and adb both exist there and users can experiment. Termux on Android can run the jar, but the README points elsewhere for instructions. If you need a supported, documented path on macOS or on ARM Linux without supplying your own adb, this project does not offer one.

Finally, the interface is a phone-side two-pane file manager. There is no desktop GUI mentioned in the README; the computer side is a jar with command-line flags. Anyone expecting a desktop window with drag and drop will be disappointed.

Alternatives and How They Differ

The obvious comparison is a plain adb pull or a single-link file transfer. Those use one channel and one path. HybridFileXfer's distinguishing claim is that it aggregates several interfaces and reassembles the blocks in order on the receiving side. If your bottleneck is a single slow link, aggregation is the entire point; if your bottleneck is the phone's flash read speed, adding channels will not help.

Wireless transfer apps that expose an HTTP server on the phone are a different approach. They typically use whatever WiFi link the phone has, present a browser interface, and require no desktop client at all. That is simpler to start and works from any device with a browser, but it cannot use USB as a data path and it does not aggregate interfaces. HybridFileXfer trades that simplicity for the ability to combine USB and two WiFi bands.

Cloud sync tools solve a different problem. They add an upload and a download, and they assume network access to a provider. HybridFileXfer is direct and local, which is why the README's speed figures are stated in terms of LAN interfaces rather than internet bandwidth.

Within the project's own scope, the closest thing to an alternative is the USB tethering fallback the README itself suggests when ADB is unavailable. It is not a competing tool; it is a different way to reach the same app.

Licence, Maintenance, and Upgrade Cost

The project is licensed GPL-3.0. That matters if you intend to redistribute a modified build or embed the client in a product: the licence carries copyleft obligations, and this article is not legal advice on how those apply to your distribution. The repository also contains a sponsorship list file, which is separate from the licence.

The last push to the default branch was on 2026-08-16, which is recent enough that the repository is not dormant. The latest release listed is v3.0.0 from 2025-03-12, followed by v2.2.0 and v2.1.1 earlier in 2025. The gap between the last push and the last tagged release suggests that work continues on the branch without a matching release tag, though the README does not describe a release cadence.

Upgrade cost is low in the normal case: the desktop side is a jar, and the README's Linux instructions are a package install through an AUR helper. The Android side is an APK. The README does not document a migration path between major versions, so if a future release changes the wire protocol, the desktop and phone sides would need to move together. Nothing in the README states a compatibility guarantee across versions.

Editorial conclusion

Adopt HybridFileXfer if you regularly move large files from a phone to a computer and can run a Java client, with USB debugging enabled or a USB tethering fallback. Skip it if you need a progress bar, a drag-and-drop GUI on the desktop side, or a phone-to-phone workflow without a PC in the middle. Before committing, verify three things on your own hardware: that your phone exposes more than one usable interface in the network card list, that the Android/data directory you need is reachable in ROOT mode, and that the Java client connects with the exact -c flag you intend to use.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. weixiansen574/HybridFileXfer on GitHub