Dextop turns a phone into a desktop with virtual displays

A virtual display and a window manager

Dextop is an open source Android app that creates a virtual display and provides a desktop like workspace using only a smartphone. The interesting part is the version note. Dextop 1.5.0 and later include a built-in privileged access runtime, which works with Android system services to control app launching, window placement, touch input, orientation and related desktop behaviour. So the app is not drawing a fake desktop picture, it is using privileged access to system services to make Android itself behave like a desktop environment, and the workspace, the panes and the launcher are all consequences of that access rather than of a remote session or a virtual machine. The distribution is ordinary Android, on the Play Store and as a GitHub release, and the project is developed in the open with a Discord server for bug reports, device reports and feature requests.

The feature list is a window manager checklist

The feature list is long, and it reads like the feature list of a desktop environment rather than of an app. On the display side there are virtual displays with configurable resolution, density and portrait or landscape orientation, secure display and Android system decoration controls, and a multi-display topology with saved monitor placement and cross-display pointer routing. On the window side there is a desktop app launcher, workspaces that save and restore the placement of multiple apps, two-pane, three-pane, four-pane and other window layouts, and workspace import and export as JSON. On the input side there are cursor and direct-touch modes, tap, long-press, drag, right-click, two-finger and three-finger gestures, multi-touch including scrolling and pinch to zoom, physical mouse and keyboard support, and routing of mouse and keyboard input between Dextop and the external display on supported devices. Then there are the platform specific pieces, automatic desktop taskbar hiding with optional built-in display 120 Hz enforcement, a foldable laptop mode with a US keyboard, trackpad, manual overlay control and optional hinge-angle detection, a switchable virtual gamepad with ABXY, triggers, sticks, a D-pad and Start, Select and Home buttons, and separate Android Auto Parking and Driving companions with automatic head-unit sizing.

The operational details are unusually complete

A few entries in the feature list are about the app surviving contact with a phone rather than about the desktop itself, and they are the ones that usually go undocumented. There is a performance overlay for FPS, refresh rate, memory, battery and estimated power usage. There is a Quick Settings tile launch, so the app is reachable without opening it. There is interrupted-session recovery with restoration of temporary Android settings, which matters because the app changes system settings to make the desktop work and has to put them back. And there are detailed diagnostic reports containing app logs, capability probes, fallback results and device specifications, plus localized device compatibility reports with per-feature results and automatic email composition, which is how a user is expected to submit one of those community reports. The interfaces are available in Japanese, English, Chinese, Korean and Russian, and the documentation is published in English, Japanese, Simplified Chinese and Korean.

Compatibility is the real constraint

The compatibility table is the most useful part of the README, and it is blunt. Samsung DeX on One UI 8 or later is fully supported and described as currently the most complete environment, with features managed by DeX using Samsung's own platform implementation. Samsung DeX on an earlier release than One UI 8 is limited and likely incompatible, because older DeX implementations may not provide the display and window management behaviour Dextop needs. Google Pixel is limited and incomplete, depending on Android's freeform and desktop implementation and on hidden API availability, with some features possibly not working. OPPO ColorOS desktop is limited and incomplete, where the desktop can be displayed but platform components such as the taskbar may not appear. Xiaomi devices running HyperOS or later are marked disabled, with MIUI and HyperOS not supported. Everything else is experimental, with virtual display, mirroring and freeform support varying by manufacturer, model and OS update. The mechanism behind that spread is stated next, since Dextop probes device capabilities at runtime and tries compatible backends in order, but it still depends on Android hidden APIs and OEM behaviour, so results can differ between models and OS versions from the same manufacturer.

Device reports are the real documentation

Because the compatibility depends on firmware rather than on model, the project treats user reports as documentation. There is a long list of tested devices, each with its model code, the exact software it was tested against and a status, and each table is labelled as a community-submitted and reviewed device report. The Samsung list shows what that means in practice, with a Galaxy S26 on Android 16 and One UI 8.5 marked as confirmed working, a Galaxy Z TriFold on Android 16 and One UI 8.0 also confirmed, a Galaxy Z Fold8 on Android 17 and One UI 9.0 confirmed, a Galaxy Z Fold7 on Android 16 and One UI 8.0 confirmed, and a Galaxy Z Fold3 5G on Android 15 and One UI 7.0 marked as not working at this time. The Google list has a Pixel 9a on Android 17 marked as partial, and the HONOR list has a Magic 8 Pro on Android 16 marked as experimental. The status wording only applies to firmware versions that were actually tested, and a per-feature breakdown lives in a device compatibility wiki.

Android Auto is a separate integration

The Android Auto support is worth pulling out because it works in a different direction from the rest of the app. It is exposed through a parked CAR_LAUNCHER activity and a separate Android for Cars App Library driving service on Android 15 and later, and the Android Auto host decides whether each entry is shown and which input events it supplies. That last clause is the design: Dextop registers a launcher entry and a driving service, and the head unit decides what to display and what input to send, rather than Dextop pushing a UI into the car. The Parking and Driving companions are separate apps in the list, with automatic head-unit sizing, parked full-touch input and phone-side driving controls, so the phone stays in the role of the input device while the head unit does the rendering.

The build environment and the release state

The repository mixes an Android native tree under android/ with a Flutter project at the top level, where pubspec.yaml, lib/, l10n.yaml and analysis_options.yaml sit alongside assets/, docs/, test/, tool/, tools/ and third_party/, and the project records Kotlin as its primary language. The build configuration lives in an environment file, and the template is explicit that it is to be copied to .env and that the real file and keystore must never be committed:

DEXTOP_KEYSTORE_FILE=android/keystore/dextop-upload.jks
DEXTOP_KEY_ALIAS=dextop-upload
DEXTOP_STORE_PASSWORD=replace-with-a-long-random-password
DEXTOP_KEY_PASSWORD=replace-with-a-long-random-password

# Optional Google Play Developer API service-account JSON path.
PLAY_SERVICE_ACCOUNT_JSON=/absolute/path/to/play-service-account.json
PLAY_TRACK=internal

with a Google Cast SDK Console application id for the cast receiver in the docs. The project is GPL-3.0 licensed, publishes on the Play Store and as GitHub releases, and the release history shows 1.7.0 on 2026-09-14 after 1.6.9 and 1.6.8 on 2026-09-09, with the last push to the repository on 2026-10-18, so it is actively worked on. There is a changelog, a code of conduct and contribution guide in both English and Simplified Chinese, and the project keeps a set of localized device compatibility reports, which tells you that the support burden is a large part of what this repository does.

Editorial conclusion

Dextop fits an owner of a recent Samsung handset who wants to use their phone as a small desktop, particularly for a foldable in laptop mode, since those are the configurations the project reports as confirmed working and it turns a phone screen into something closer to a workstation. It does not fit a Xiaomi device, where the project marks support as disabled, and it does not fit anyone who needs a guaranteed experience across manufacturers, because the compatibility table is explicit that the behaviour varies by model and OS version. Before you install it, read the compatibility section for your exact model and firmware, and check the community device report for that entry, because the difference between a Galaxy S26 and a Galaxy Z Fold3 in the same table is the difference between working and not working.

Frequently asked questions

Official sources

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