bVNC, aRDP, aSPICE and Opaque: the Android remote desktop clients in iiordanov/remote-desktop-clients

Four clients, four protocols, one Android codebase

The repository is not a single application. It is the shared source for bVNC (VNC), aRDP (RDP), aSPICE (SPICE) and Opaque (oVirt, RHEV and Proxmox), each published separately on Google Play, Amazon App Store and, for bVNC, aRDP and aSPICE, the Apple App Store. The Android and BlackBerry 10 clients live here; the README points to a separate GitLab repository for the iOS and macOS source.

The audience is narrow and specific. This is for someone who administers machines over VNC or RDP from a phone or tablet, or who runs virtualisation on oVirt, RHEV or Proxmox and needs a console client that speaks the management platform's protocol rather than raw VNC. It is also for people who want the source: the top level carries separate app directories (bVNC-app, aRDP-app, aSPICE-app, Opaque-app, plus the free variants freebVNC-app, freeaRDP-app and freeaSPICE-app) and a shared remoteClientLib module. If you want a desktop client for Windows, macOS or Linux, nothing here addresses that, and the README does not claim otherwise.

How the shared library and the per-app directories fit together

The layout separates protocol and UI code from the packaging of each product. remoteClientLib holds code shared across clients, and it is also where custom certificate authorities go: the README says you can add custom CAs for aSPICE and Opaque in remoteClientLib/certificate_authorities/, and that they are merged with the ca-bundle.crt provided to the app so self-signed server certificates validate. That single directory is the most consequential extension point in the repository for anyone running internal infrastructure with private CAs.

The bVNC directory carries the build tooling rather than an app: prepare_project.sh is invoked with a PROJECT argument, and the README describes setting PROJECT to libs for a non-custom client or to a string that starts with Custom and contains Vnc for a custom VNC client, for example CustomYourVncClient. That naming convention is a build-time switch, not a runtime one, and it is the mechanism by which a branded VNC client is produced from this tree. The bVNC/layouts directory holds convert.py, which generates keyboard layouts for the desktop clients; the README suggests creating a file in the format expected under /usr/share/qemu/keymaps/ to add one. freeRDPCore is an external module pulled in as a submodule, which is why the import step below requires editing its Gradle file.

Building bVNC on Linux with prebuilt dependencies

The README offers three build routes on Linux and WSL2 (prebuilt libraries, Docker, or from scratch) and says the instructions should work on Ubuntu 18.04 and 20.04. The fastest is the prebuilt path: two commands from the repository root, the first fetching dependencies and the second preparing the project without compiling the native libraries.

./download-prebuilt-dependencies.sh
./bVNC/prepare_project.sh --skip-build libs nopath

The libs argument selects the non-custom client, matching the PROJECT convention described above. After this, the README says to open the directory as an existing Android Studio project, and notes one required edit: open build.gradle (Module freeRDPCore) under Gradle Scripts and change minSdkVersion to 11. Without that change the project does not build. Then Build, Make Project.

On Windows without WSL2, only the prebuilt route is supported. After installing Git and starting Git Bash, the README gives a single command:

./download-prebuilt-dependencies.sh

Then open the project in Android Studio and use File, Sync Project with Gradle Files. The README warns that Android Studio may report missing Android versions and names android-28, android-29 and android-30 as the versions required at the time of writing, with other versions needed later if the IDE reports an error. The from-scratch path is a different order of magnitude: the README states the build script takes hours to run.

The Docker route and the from-scratch package list

If you would rather not install the native toolchain on your host, the README documents a Docker Compose build. It must be run from the project root, and ANDROID_SDK must point at your SDK installation.

echo "USER_UID=$(id -u)" > docker/.env
echo "USER_GID=$(id -g)" >> docker/.env
echo "CURRENT_WORKING_DIR=$(pwd)" >> docker/.env
docker-compose -f docker/docker-compose.yml up

The three variables written to docker/.env exist so the container runs as your user and can see the working directory. This is the only build path in the README that does not assume a pre-populated host toolchain.

The from-scratch path on the host needs gnome-common, gobject-introspection, nasm, gtk-doc-tools and python-is-python3, installed on Ubuntu with apt. You then set ANDROID_SDK, add the SDK's platform-tools and tools directories to PATH, run the sdkmanager license acceptance command, and invoke prepare_project.sh with the project name and SDK path. The README's own example uses:

export PROJECT=libs
export ANDROID_SDK=${HOME}/Android/Sdk
export PATH=$PATH:${ANDROID_SDK}/platform-tools/
export PATH=$PATH:${ANDROID_SDK}/tools

It also advises choosing x86_64 for an emulator to avoid "has text relocations" errors when loading gstreamer on Android. That detail matters because it is a runtime failure, not a build failure, and it appears only in the from-scratch section.

Where this repository is the wrong tool

The README does not document rollback, downgrade or migration between releases, so if you are deploying a custom build to a fleet of devices, you are on your own for version management. It also does not describe a supported API or library interface for embedding these clients in another Android application. The custom-client mechanism is a build-time PROJECT name convention, not a documented SDK. If your goal is to add VNC or RDP to your own app, this tree gives you code to read, not an integration surface.

The build instructions carry their own risk. They are pinned to specific Android SDK versions (android-28, android-29, android-30) and the README acknowledges that future versions will need to be installed when Android Studio complains. The freeRDPCore minSdkVersion edit is a manual step in an external module, and manual steps in submodules are the kind that break silently when the submodule moves. The from-scratch build is measured in hours, which makes it a poor fit for a quick evaluation. And the platform scope is Android and BlackBerry 10; the README sends iOS and macOS users to a different repository entirely.

How it differs from Microsoft Remote Desktop and other clients

Microsoft's Remote Desktop client is an RDP client, and RDP is the only protocol it speaks. This repository covers RDP through aRDP but also VNC through bVNC, SPICE through aSPICE, and the oVirt, RHEV and Proxmox management protocols through Opaque. The practical difference is what you point the client at. With an RDP-only client, a Proxmox host or a SPICE console is out of reach; with Opaque, the README describes a client built for those platforms specifically.

The second difference is distribution and licensing. Microsoft's client is a closed product you install from a store. This repository is GPL-3.0 source that you compile yourself, with free and donation builds published on Google Play, Amazon App Store, IzzyOnDroid and the Apple App Store, and Pro APKs distributed to Patreon members. That matters if you need to inspect the code, patch it, or add a private CA through remoteClientLib/certificate_authorities/ so the client trusts an internal certificate authority. A store-only client gives you no equivalent hook. The trade-off is that you own the build: the SDK versions, the freeRDPCore edit and the multi-hour compile are yours to maintain.

Licence and the cost of keeping a fork alive

The repository is licensed GPL-3.0, and the README defers to the LICENSE file for the terms. The top level also carries COPYRIGHT-bVNC and COPYRIGHT-Opaque files, so the copyright notices are split per product rather than consolidated. GPL-3.0 is a copyleft licence, which has consequences if you distribute a modified build: the source you ship has to be available under the same terms. That is a question for your own legal review, not something this article can settle.

The upgrade cost is the more immediate concern. Releases are tagged and the free APKs are published on the GitHub releases page, but the build instructions are tied to Android SDK versions and to an external submodule that needs a manual edit. Every time you rebuild, you re-verify that freeRDPCore still needs minSdkVersion 11 and that your installed SDK versions still satisfy Gradle. The last push to the default branch was on 2026-08-31, and the most recent release tag is RELEASE-v6.4.9 from the same day, so the tree is current as of that date. Budget for the rebuild, not just the first build.

Editorial conclusion

Adopt this repository if you need an Android client for VNC, RDP, SPICE or oVirt/RHEV/Proxmox and you want the source, or if you need to add a private CA so the app trusts a self-signed server certificate. Do not adopt it if you want a desktop client, a web client, or a library you can drop into another Android app: the README documents none of those. Before building, confirm your Android SDK path, check that the freeRDPCore module's minSdkVersion is set to 11, and decide whether the hours-long from-scratch path is worth it against ./download-prebuilt-dependencies.sh.

Frequently asked questions

Official sources

1. iiordanov/remote-desktop-clients on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases