whoozle Android File Transfer for Linux review: MTP GUI, CLI and FUSE

Why android-file-transfer-linux exists

This project targets the awkward part of moving files between a computer and an Android device over MTP. MTP is not a mounted disk in the same way as many Linux filesystems. Devices expose media objects, metadata and storage locations through a protocol, and the experience depends heavily on the client. The README positions this software as a client for people who are unhappy with `gmtp`, `gvfs`, `mtpfs` or other MTP software.

The stated problem is narrower than general file synchronization. The project is for USB-connected Android devices, with additional support for Zune and Zune HD. It does not describe wireless transfers, cloud backup, Android debugging, media streaming or remote file access. Its practical audience includes Linux users who want a desktop application similar in purpose to Android File Transfer, command line users who need `aft-mtp-cli`, and users who prefer to browse device files through a FUSE mount.

The metadata angle is important. The README specifically mentions missing tags, album covers and corrupted files as problems that may justify trying this client. It also documents automatic album cover renaming so that media players can see the cover. Those claims describe the project's intended target, but they are not a guarantee that every device, Android version or media library will behave identically.

The project is not archived, and its last push was on 2026-10-11. Recent releases include v4.6 on 2026-10-11, v4.5 on 2025-05-14 and v4.4 on 2025-03-31. That release history indicates continued release activity around the current version, while the README describes development as work done in spare time.

Qt, CLI, FUSE and library surfaces

The repository exposes several ways to interact with the same MTP-oriented codebase. The Qt directory contains the graphical program, the `cli/` directory contains the command line client, the `fuse/` directory contains the mount integration, and the `mtp/` directory contains the underlying project code. The README also lists a static or shared library and Python bindings as available features.

The Qt application is presented as a simple interface with progress dialogs. Its value is that it gives a user a visible transfer workflow rather than requiring every operation to be expressed through a terminal. The screenshot and README specifically mention device-generated thumbnails, although the documentation does not give a detailed account of thumbnail cache handling or transfer cancellation behavior.

The command line surface is `aft-mtp-cli`. The repository links to its manual page, but the README does not reproduce its commands or options. That omission matters for evaluation: a command line tool's usefulness often depends on exact flags, selection syntax, output format and error handling, and those details cannot be inferred from the feature list.

The FUSE interface provides a filesystem-style view. The documented first operation creates a mount directory and runs `aft-mtp-mount` against it. The README says this mode supports partial reads and writes, which allows immediate access to files without waiting for a complete copy. It also warns that FUSE can be 7 to 8 times slower than UI or CLI file transfer. That is a direct trade-off between convenience and throughput. FUSE users are also instructed to place an `albumart.xxx` file first in the destination folder if album art should be displayed.

Python support is configured through `pyproject.toml`. The package name is `android-file-transfer-linux`, the version is `4.6`, and the build uses `scikit-build-core` with `pybind11`. The CMake configuration explicitly disables `BUILD_FUSE` and `BUILD_QT_UI` for the Python build, so the Python distribution should not be assumed to include the desktop or mount front ends.

Installing packages on Linux, FreeBSD and macOS

On Debian and Ubuntu, the documented package installation is a single command. The package manager supplies the application, so this is the shortest path for a user who does not need to build from source.

sudo apt-get install android-file-transfer

After installation, the README does not give a separate launch command for the Debian or Ubuntu package. The distribution's installed executable or desktop entry would be the relevant place to look, but that detail is not documented in the README.

Arch documents a comparable package through `pacman`.

sudo pacman -S android-file-transfer

Gentoo is included in the Portage tree. The documented command installs the package with its ebuild and shows the available package version.

sudo emerge -av sys-fs/android-file-transfer-linux

Gentoo users who want FUSE must enable the package use flag. The README places the following line in `/etc/portage/package.use`, which can be either a file or a directory.

sys-fs/android-file-transfer-linux fuse

The README also documents a Homebrew cask for macOS. The stable and nightly casks conflict, so the project tells users to uninstall one before switching.

brew install homebrew/cask/whoozle-android-file-transfer

The nightly command is documented separately.

brew install homebrew/cask-versions/whoozle-android-file-transfer-nightly

The README also lists an AppImage on the GitHub releases page. That route may be useful on systems without a distribution package, although the README does not explain AppImage compatibility, desktop integration or required FUSE permissions.

Building and launching the Qt application

Building from source requires Qt for the graphical application. The README says that Qt is not needed if only the library is wanted and that `BUILD_QT_UI` can be turned off. For Debian-based systems, the documented prerequisite command installs the compiler toolchain, CMake, Qt packages, Ninja and development libraries.

sudo apt-get install build-essential cmake qt5-default ninja-build libfuse-dev libreadline-dev qttools5-dev

The Fedora command covers the corresponding compiler, Qt, FUSE, kernel development, CMake and readline dependencies.

dnf install make automake gcc gcc-c++ kernel-devel cmake fuse fuse-devel qt-devel readline-devel libqt5-linguist-devel

For a Ninja build, the documented sequence creates a build directory, configures the project with CMake, compiles it and launches the Qt executable from the build tree.

mkdir build
cd build
cmake -G Ninja ..
ninja
./qt/android-file-transfer

The Make variant uses the same source layout but selects CMake's default generator and `make`.

mkdir build
cd build
cmake ..
make
./qt/android-file-transfer

Installation is documented as `sudo ninja install` or `sudo make install`, with the program installed into the CMake prefix's `bin` directory, usually `/usr/local/bin`. The README does not include a systemd service, desktop database update, udev rule or Android USB permission procedure. Those omissions limit how far a build tutorial can go for a complete desktop installation.

FUSE mounting and the album-art ordering rule

FUSE is the clearest alternative to waiting for files to be copied through the UI. Create a directory for the mounted device and pass it to `aft-mtp-mount`.

mkdir ~/my-device
./aft-mtp-mount ~/my-device

The directory is the mount point. The README states that partial reads and writes allow immediate access, which can be useful for copying one item or opening a file without first transferring an entire object. It also makes operation dependent on the FUSE layer and on the device's MTP behavior rather than only on the Qt program.

The speed warning is the main constraint. According to the README, FUSE could be 7 to 8 times slower than UI or CLI file transfer. The documentation does not qualify that figure by file size, device, kernel or operation type, so it should be treated as the project's documented warning rather than a general benchmark. For large transfers, the UI or CLI is the more sensible documented choice.

Album art requires a specific copy order. The README says the cover must be named `albumart.xxx` and placed first in the destination folder, followed by the other files. This is not merely a naming convention in the project's instructions. It is presented as a requirement for media players to display the cover, which means an otherwise successful transfer can still appear incomplete if the files are copied in another order.

The Zune firmware recovery instructions in the README are a separate workflow. They require locating a firmware MSI, unpacking it with `7z`, identifying the model codename in `FirmwareUpdateXml`, and extracting a matching baseline package with `cabextract`. The README excerpt does not finish the recovery procedure, so it should not be treated as a complete firmware flashing guide.

Trade-offs against gvfs, mtpfs and gmtp

The most direct alternative mentioned by the README is to stay with `gmtp`, `gvfs` or `mtpfs`. The difference is not simply the interface. This project presents a Qt desktop application, a dedicated CLI, a FUSE mount and Python bindings, while the alternatives may fit users who already have a working desktop file manager or a simpler mounted-filesystem workflow.

`gvfs` and `mtpfs` are relevant when the main requirement is browsing the device as a filesystem. The trade-off is that users may give up the project's album-cover renaming behavior, its progress-oriented Qt interface or the documented partial read and write workflow. The README does not claim compatibility or performance comparisons with those tools, so it cannot establish that this project is faster or more reliable in every case.

The project also states that it has no extra dependency on `libptp` or `libmtp`. That can simplify deployment compared with a client built around those libraries, but it does not mean the program has no dependencies at all. A GUI build needs Qt, and the FUSE interface needs FUSE development or runtime support. The package manager or source build still has to satisfy the relevant platform requirements.

Python bindings are another distinction, but `pyproject.toml` disables `BUILD_FUSE` and `BUILD_QT_UI` for the package build. Developers should therefore treat Python integration as a library or binding surface, not as an assumption that a Python package installation creates every executable listed in the feature list.

Maintenance, licensing and upgrade scope

The repository is not archived, and the last push was on 2026-10-11. Releases listed by the repository include v4.6 on 2026-10-11, v4.5 on 2025-05-14 and v4.4 on 2025-03-31. The README says the author works on the project in spare time, so the maintenance commitment is personal rather than a documented enterprise support arrangement.

The package version in `pyproject.toml` is `4.6`, matching the listed v4.6 release. The build system requires `scikit-build-core` and `pybind11`, while the CMake settings disable the Qt UI and FUSE targets for that Python build. Upgrading from a source checkout therefore requires checking both the C++ build configuration and the Python build configuration. The README does not document migration notes, compatibility guarantees or an upgrade rollback procedure.

The repository is licensed under LGPL-2.1. The README links to the `LICENSE` file, and the repository also includes `replace-license.py` and `replace-guards.py`. The README does not explain how those scripts are intended to be used, so they should not be assumed to be part of an end-user upgrade procedure. Anyone redistributing a modified or linked build should review the actual `LICENSE` terms and dependency notices. This is a project licensing note, not legal advice.

The practical upgrade cost depends on the chosen surface. A package manager can handle the platform package, while a source build requires CMake, a compiler and possibly Qt or FUSE. The README does not document automatic device migrations, persistent settings compatibility or upgrade behavior for mounted directories.

Editorial conclusion

Adopt it when direct MTP access, album metadata handling or a FUSE workflow matter and you can supply Qt, FUSE or a supported package source. Do not choose it for wireless transfers or expect the FUSE interface to match UI and CLI speed. First verify package availability, device connection behavior and whether the required FUSE setup is acceptable. The project is not archived, and its last push was on 2026-10-11.

Frequently asked questions

Official sources

1. License: LGPL-2.1
2. Project website
3. README
4. Releases
5. whoozle/android-file-transfer-linux on GitHub