The Problem
Transferring large files between heterogeneous devices (Android, iOS, Linux, macOS, Windows) without a pre‑existing Wi‑Fi network is cumbersome. Users must rely on cloud services, USB sticks, or ad‑hoc network configuration, each introducing latency, size limits, or security concerns.
What This Does
FlyingCarpet creates a temporary Wi‑Fi hotspot (or uses Bluetooth for negotiation) on one device and streams files directly to the peer. The core networking and Bluetooth abstraction lives in the core/ crate (core/src/lib.rs, core/src/linux/.rs, core/src/windows/.rs). Platform‑specific UI layers sit in:
Android – Kotlin sources under Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/ (e.g., MainActivity.kt, Bluetooth.kt). Build is driven by Android/FlyingCarpet/app/build.gradle. Desktop/macOS/Windows – A Tauri front‑end (Flying Carpet/src-tauri/src/main.rs) bundled with web assets (Flying Carpet/src/index.html, main.js, style.css). The Tauri manifest is Flying Carpet/src-tauri/tauri.conf.json.
The Rust code implements the ad‑hoc network stack, while the web UI renders QR codes (Flying Carpet/src/deps/qrcode.js) for easy connection sharing.
How To Use It
Setup (development)
Install Rust toolchain curl https://sh.rustup.rs -sSf | sh
Install Tauri CLI (required for desktop builds)
cargo install tauri-cli
Linux desktop dependencies (example for Ubuntu 20.04)
sudo apt install libsoup2.4-dev libjavascriptcoregtk-4.0-dev \ libgdk-pixbuf2.0-dev librust-pango-sys-dev libgdk3.0-dev \ librust-atk-dev librust-atk-sys-dev librust-gdk-dev \ libwebkit2gtk-4.0-dev librsvg2-dev
Desktop – From the repository root run cargo tauri dev for a hot‑reloaded dev build or cargo tauri build for release artifacts (.AppImage, .dmg, .msi).
Android – Open Android/FlyingCarpet in Android Studio or invoke Gradle directly: cd Android/FlyingCarpet ./gradlew assembleRelease # produces APK in app/build/outputs/apk/
iOS – The iOS project is not present in the source tree; the binary is distributed via the App Store.
Configuration
No runtime configuration files are required. The hotspot SSID and passphrase are generated at runtime (see core/src/linux/network.rs and core/src/windows/network.rs). Bluetooth pairing must be performed manually on macOS/Linux as documented in the README; the code that toggles the UI switch resides in Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Bluetooth.kt.
Running
Desktop: Execute the built binary (e.g., ./target/release/flyingcarpet). The UI launches from Flying Carpet/src/index.html.
Android: Install the generated APK (androidFlyingCarpet9.0.8.apk) and launch the app; the main entry point is MainActivity.kt.
The QR code displayed (qrcode.js) encodes the hotspot credentials; the peer scans it to join automatically.
Real‑World Use
A video production team needs to move a 12 GB raw footage file from an Android tablet to a Windows workstation on set, where no internet is available. They start FlyingCarpet on the tablet, enable “Use Bluetooth” for faster negotiation, scan the QR code displayed on the Windows app, and the file streams over the ad‑hoc Wi‑Fi link without touching external storage or cloud services.
Code Health & Issues
Med – Missing CI/CD – No GitHub Actions or other pipelines; .github/ contains only FUNDING.yml. Automated builds/tests are absent. Low – Limited test coverage – Only two test files (core/src/lib.rs tests and Android unit test) exist; core networking paths are not exercised. Med – Platform parity gaps – iOS source code is not in the repo; the binary is distributed only via the App Store, making local builds impossible. Low – Android device compatibility – README notes failures on certain Xiaomi/MIUI devices; the code relies on LocalOnlyHotspot without fallback, which may cause runtime crashes on unsupported hardware. Low – License – The repository includes LICENSE.txt (presumably MIT/Apache) but the file content should be verified for compatibility with downstream use.
Overall the Rust core is well‑structured with separate modules for Linux and Windows, and the Tauri front‑end follows standard conventions. No obvious secret keys or hard‑coded credentials are present.
The Bottom Line
FlyingCarpet delivers a functional, cross‑platform ad‑hoc file transfer solution with a clean Rust core and native UI wrappers. It is ready for internal testing or small‑scale deployment, but the lack of automated CI, sparse test suite, and missing iOS source limit confidence for enterprise‑grade adoption. Teams that can tolerate manual build steps and perform their own QA will find it a practical alternative to cloud‑based transfers.