droidVNC-NG: a rootless Android VNC server built on MediaProjection and accessibility

MediaProjection for the picture, an accessibility service for the keys

The design constraint of this project is that it cannot ask for root, so it has to build a remote control out of the two mechanisms Android offers an ordinary app. The picture comes from screen capture through the modern media projection API, and the repository's own topic tags include mediaprojection, which is the giveaway that the screen is a captured stream rather than a framebuffer read. The input side has no such API, so the app uses an accessibility service instead, and the README says so plainly: to control the device remotely with mouse and keyboard, you need to activate the AccessibilityService for the app on your device. That is the honest core of the project and the part a security reviewer should read first, because an accessibility service is a high privilege grant that most users enable without reading what it permits. What you get for it is a real desktop. Keyboard shortcuts on the viewer side stand in for hardware keys, with Ctrl-Shift-Esc opening the recent apps overview, Home or Pos1 acting as the home button, End as the power button, Escape as back, and Ctrl-Alt-PageUp and PageDown moving the volume. Clipboard transfer works in one direction without any setup, for text selected in an editable field, and in the other direction by sharing text into the app through Android's share target.

libvncserver, libjpeg-turbo and noVNC all sit in the tree as submodules

The top-level file list explains where the protocol handling comes from. Alongside the app module, the build files and the fastlane directory for store releases, there are three vendored dependencies: libvncserver, libjpeg-turbo and noVNC. That is the honest answer to what droidVNC-NG actually is. It is not an RFB implementation written from scratch; it embeds the C library that speaks the protocol and the JPEG encoder that makes framebuffer updates cheap over a slow link, and it adds the Android side around them, being the capture, the input injection, the activity lifecycle, the preference handling and the admin panel. The third vendored piece is a complete noVNC checkout, which is why the project can offer a browser client without requiring a separate viewer: the same server that speaks RFB to a native client serves a web client to a browser, so a machine with nothing installed can still connect. Two practical consequences follow. The build needs those submodules present before anything compiles, so a plain clone is not a buildable tree:

git submodule update --init
gradlew

And the GPL-2.0 grant in the repository covers a codebase that contains two C libraries and a JavaScript client, which is worth knowing if you ever need to reason about redistribution. The README keeps its own documentation short on this and defers the detail to separate documents for preseeded preferences and for the intent interface.

Three ways in: a listening port, a reverse connection, or a browser

The connection design is where this project is more considered than a typical VNC server, and there are three distinct paths. The plain one is a listening VNC server on a port you choose, reachable from anything on the local network, with the device discoverable automatically over Zeroconf or Bonjour so a viewer can find it without being told an address. The second is reverse VNC, and it exists to solve a real problem. Instead of listening, the app dials out to a viewer that is already listening, or to a mediator in the UltraVNC style mode 2 repeater arrangement, and the VNC port field is left blank, which makes the admin panel state plainly that the server is not accepting incoming connections. No port is opened on the router, and the outbound connection can be retried a set number of times, with a default of zero meaning no reconnect at all, and the same value can be supplied as EXTRA_RECONNECT_TRIES through the intent interface. That is the mode to use for a device behind a router you do not control, and it inverts the usual trust question: nothing on your network has to be exposed for the connection to exist. The third is the browser path through the bundled noVNC client, so a machine with no VNC software installed can still take control, which is the practical argument for keeping the whole client in the tree. Each connected client gets its own mouse pointer drawn on the device screen, which is a small courtesy with a security reading: a person standing next to the phone can see that a session is live and where the pointer is.

The internet section, the plaintext disclaimer, and what file transfer really supports

The README contains a section on reaching the device from outside the local network, and it opens with a disclaimer that deserves to be quoted rather than paraphrased: anything other than the password exchange is not currently encrypted, so use it at your own risk. Everything after that is a walk through opening a port on a home router, and the project is being straightforward about the risk rather than hiding it. The network reality is the rest of the story. An unencrypted RFB session on port 5900 carrying keystrokes to a device that may be unlocked is a full remote control channel, and the only protection in the path is a password exchanged at the start. That is why the reverse connection mode exists, and it is the mode to reach for instead. Two smaller things in the same area are easy to miss. The port forwarding guidance notes that leaving the internal address as any is less secure and that the device's address may change over time, which is a warning about your own home network configuration more than about the app. And the file transfer feature is narrower than the rest: it works with the Windows build of TightVNC viewer at version 1.3.x, so anyone on macOS or Linux, or on a different TightVNC release, has a screen and no file transfer. A password is also mandatory if you intend to use the built-in Screen Sharing application on macOS, which is a client requirement rather than a security setting.

Input capability changes at Android 14, and older devices get EditText only

The version boundary in the feature list is the detail that decides whether the tool is usable for a given job. Remote control with mouse and keyboard is described as supporting any kind of UI widget on Android 14 and newer, while on older devices it works into EditText widgets only. That is a hard limit, not a gradual degradation. On a recent phone, a remote operator can drive the settings app, dismiss dialogs and scroll through anything on screen. On a device below Android 14, the same gesture only produces text where text can be focused, so the practical use on an old handset narrows to typing into a form, which is a different product from the one the screenshots show. The second boundary is operational. Because input rides on an accessibility service, the permission has to be on for the feature to work at all, and there is no fallback path: with the service disabled, the picture keeps streaming and every click goes nowhere. That combination, a screen that looks live but does not respond, is the failure mode most likely to cost someone an hour of debugging, and it is not an error the app raises. If you are setting this up on someone else's device, the accessibility grant deserves the same explanation you would give for any other high privilege permission, including what it means that the app can see the screen contents and send events anywhere.

Kiosk devices, preseeded preferences and an intent interface for automation

Three deployment features sit outside the ordinary personal use case, and they are what turn this into something a team can roll out. The first is autostart. The server can start when the device boots, and on Android 11 and newer that also works with kiosk mode launchers and lock task mode, which are the configurations used for a dedicated device that is not supposed to leave one app. On such a device a VNC server is the standard escape hatch for support and for content, since the operator can see and fix a screen that is otherwise locked into a single task. The second is preseeding. Preferences can be supplied by a JSON file or through mobile device management managed configurations, and the documented semantics are that these are defaults which apply only where the user has not already changed the setting, so a device owner can still override them. That distinction matters for MDM, because it means a pushed default will not fight a user's explicit choice, and it also means a configuration rollout cannot be used to force a setting on a device that has already been touched once. The third is the intent interface, which starts the server from other apps or on events, and the README names the automation apps it is designed around, MacroDroid, Automate and Tasker, as well as plain code. Combined with the reconnect setting exposed there, the intent interface is the seam for a device that needs to come up and be reachable without anyone touching it.

v2.22.0 in September 2026, GPL-2.0, and a package id from an earlier author

The maintenance signal here is unusually healthy, and the project is small enough that the record is readable. The last push was on 2026-09-24, and the three recent releases are v2.20.3 on 2026-08-03, v2.21.0 on 2026-08-25 and v2.22.0 on 2026-09-17, so roughly one release a month across a two digit version line that is not yet at three. Releases are published through F-Droid and Google Play rather than as repository artefacts, and the fastlane directory at the top of the tree is the automation for that path, which is why there are no build binaries in the release list at all. The licence is GPL-2.0 with the text in the COPYING file, which is the natural choice for a server component that people self build and modify, and it covers the vendored C libraries as well. The provenance is worth understanding if you are following the wrong repository. The app is listed on both stores under the package identifier net.christianbeier.droidvnc_ng, while the repository you are reading belongs to bk138, and the README explains the name by saying the project is named in reverence to an earlier droid VNC server. So there is a lineage of at least two prior projects, and the store listing is the one to check when you want to know which build you are actually installing. Support is split by purpose, with general questions directed to a chat room and bugs and feature requests to the issue tracker, which is a small but useful signal about where a question will get answered.

Editorial conclusion

droidVNC-NG is a good fit for a lab device on a network you control, a kiosk or lock task mode handset, and the awkward case of a phone you need to reach but cannot port forward, since reverse VNC to a listening viewer solves exactly that problem. It is the wrong choice for a device you intend to expose to the internet, because the README states plainly that nothing beyond the password exchange is encrypted, and an unencrypted RFB session carrying keystrokes to an unlocked phone is not a risk worth taking for convenience. The other boundary is the permission model: screen capture needs a MediaProjection grant and remote control needs the app's accessibility service switched on, which is a grant most people grant without reading what it permits, and the input capability differs by Android version, with full widget support arriving on Android 14 and older releases limited to editable text fields. Verify three things before deploying it: which of the three connection modes your network allows, that the password is set even if you think the LAN is trusted, and the accessibility grant in the app's settings, since input silently does nothing without it.

Frequently asked questions

Official sources

1. bk138/droidVNC-NG on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases