Skip to main content

Application Compatibility

This reference covers the compatibility status of common Linux applications when running under ADL. Applications are tested on ARM64 (aarch64) within the proot environment. Status ratings reflect typical behavior across supported Android devices.

Web Browsersโ€‹

๐Ÿ“‹Compatibility
ItemStatusNotes
Firefoxโœ…Best option for ADL. Runs reliably with good performance.
Chromiumโš ๏ธRequires launch flags (--no-sandbox --disable-gpu). May crash on low-RAM devices.
Midoriโœ…Lightweight WebKit-based browser. Good for low-resource devices.
Epiphany / GNOME Webโœ…WebKit-based. Works well for basic browsing.
Lynxโœ…Terminal-based browser. No graphical dependencies.
w3mโœ…Terminal-based browser with inline image support in some terminals.

Text Editorsโ€‹

๐Ÿ“‹Compatibility
ItemStatusNotes
Vim / Neovimโœ…Fully functional. Recommended terminal-based editor.
Nanoโœ…Simple and reliable. Pre-installed in most distributions.
Geanyโœ…Lightweight GUI editor with syntax highlighting and basic IDE features.
Mousepadโœ…XFCE default text editor. Fast and minimal.
Emacsโœ…Both terminal and GUI modes work correctly.
Sublime TextโŒNo ARM64 Linux build available from the vendor.
Kateโš ๏ธFunctional but pulls in heavy KDE dependencies. Use Geany instead.

IDEs and Development Environmentsโ€‹

๐Ÿ“‹Compatibility
ItemStatusNotes
VS Code / Code-OSSโš ๏ธNative builds have display issues under proot. Use code-server instead.
Code-Serverโœ…Browser-based VS Code. Recommended IDE solution for ADL.
Geanyโœ…Lightweight IDE with project management, build commands, and plugin support.
Thonnyโœ…Python-focused IDE. Good for learning and small projects.
EclipseโŒToo resource-intensive. Exceeds available memory on most devices.
Android StudioโŒCannot run nested Android emulation. Not functional under proot.
โœ…๐Ÿ’ก Browser-Based IDEs

code-server provides the full VS Code experience through a browser tab, avoiding the display and performance issues of native desktop VS Code under proot. Install it with the official install script and access it at localhost.

Office and Documentsโ€‹

๐Ÿ“‹Compatibility
ItemStatusNotes
LibreOfficeโš ๏ธRuns but is resource-heavy. Expect slow startup and high memory use.
AbiWordโœ…Lightweight word processor. Opens common document formats.
Gnumericโœ…Lightweight spreadsheet application. Fast and capable.
Evinceโœ…GNOME document viewer. Handles PDF and other formats well.
Okularโš ๏ธWorks but brings in KDE dependencies. Prefer Evince or Zathura.
Zathuraโœ…Minimal, keyboard-driven PDF viewer. Very fast.

Media Playersโ€‹

๐Ÿ“‹Compatibility
ItemStatusNotes
VLCโš ๏ธAudio playback works. Video may lag without hardware acceleration.
MPVโš ๏ธAudio works well. Video performance varies by device and resolution.
Audaciousโœ…Lightweight audio player. Reliable for music playback.
Celluloidโš ๏ธMPV frontend. Same video limitations as MPV apply.
ffmpegโœ…CLI media tool. Encoding, decoding, and conversion all work.
ImageMagickโœ…CLI image processing. All operations work as expected.

Graphics and Image Editingโ€‹

๐Ÿ“‹Compatibility
ItemStatusNotes
GIMPโš ๏ธRuns but can be slow on lower-end devices. Usable for light editing.
Inkscapeโš ๏ธHeavy resource usage. Functional for simple vector work.
Fehโœ…Fast CLI image viewer. Minimal resource usage.
Ristrettoโœ…XFCE image viewer. Lightweight and responsive.
Shotwellโš ๏ธPhoto manager. Import and basic editing work but performance varies.
Drawingโœ…Simple raster image editor. Good alternative to GIMP for basic tasks.

Development Toolsโ€‹

๐Ÿ“‹Compatibility
ItemStatusNotes
Gitโœ…Fully functional. All operations work as expected.
Python 3โœ…Interpreter and pip work correctly. Most pure-Python packages install fine.
Node.jsโœ…Available via package manager or nvm. npm and npx work.
GCC / G++โœ…Compiles C and C++ for ARM64. Performance is device-dependent.
Make / CMakeโœ…Build systems work without issues.
DockerโŒRequires kernel features unavailable under proot. Not functional.
Java / OpenJDKโœ…JRE and JDK available. Maven and Gradle work.
Rubyโœ…Interpreter and gem install work correctly.
Goโœ…Compiler and toolchain work. Cross-compilation supported.
Rustโš ๏ธCompiles correctly but compilation is slow due to high resource demands.

Terminal Emulatorsโ€‹

๐Ÿ“‹Compatibility
ItemStatusNotes
xfce4-terminalโœ…Default ADL terminal. Reliable and well-integrated with XFCE.
xtermโœ…Minimal terminal emulator. Always available as a fallback.
Sakuraโœ…Lightweight VTE-based terminal with tabs and configuration.
Alacrittyโš ๏ธRequires OpenGL support. May fail on devices without GPU passthrough.
KittyโŒRequires GPU rendering. Not compatible with proot display layer.

System Utilitiesโ€‹

๐Ÿ“‹Compatibility
ItemStatusNotes
Thunarโœ…XFCE file manager. Default in ADL, works well.
PCManFMโœ…Lightweight file manager. Good alternative to Thunar.
htopโœ…Process viewer. Shows proot-visible processes.
Neofetch / Fastfetchโœ…System info display. Reports the proot environment details.
Synapticโš ๏ธPackage manager GUI. Works but apt operations may need manual fixes under proot.
GPartedโŒRequires direct disk access. No real block devices available under proot.

Compatibility Notesโ€‹

Why Some Applications Do Not Workโ€‹

Several factors can prevent applications from running correctly under ADL:

  • No kernel access. ADL runs inside proot, which intercepts system calls in userspace. Applications that require direct kernel features (cgroups, namespaces, device nodes) will fail. This affects Docker, GParted, and similar system-level tools.
  • No GPU acceleration. The proot display layer does not provide hardware-accelerated OpenGL or Vulkan. Applications that require GPU rendering (Kitty, Alacritty) will not start or will fall back to software rendering with poor performance.
  • ARM64 architecture only. ADL runs on the device's native ARM64 architecture. Applications that only ship x86_64 binaries (Sublime Text) cannot run without an emulation layer, which ADL does not provide.
  • Resource constraints. Mobile devices have limited RAM and CPU compared to desktop hardware. Resource-intensive applications (Eclipse, LibreOffice, GIMP) may run but with degraded performance, especially on devices with 4 GB RAM or less.

Finding Alternativesโ€‹

When a preferred application is not compatible, look for lightweight alternatives that achieve the same goal:

  • Prefer GTK applications over Qt/KDE applications to reduce dependency overhead.
  • CLI tools often work better than their GUI equivalents under resource constraints.
  • Browser-based tools (code-server, web-based office suites) bypass many display layer limitations.
โญBest Practice

Choose lightweight alternatives whenever possible. Applications designed for low-resource environments (Geany over VS Code, AbiWord over LibreOffice, Zathura over Okular) will run faster, use less memory, and provide a more responsive experience under ADL. Reserve heavy applications for tasks where no lightweight alternative exists.

โš ๏ธContainer and Virtualization Tools

Tools that require kernel-level isolation (Docker, Podman, LXC, VirtualBox) are not compatible with ADL. The proot environment does not expose the necessary kernel interfaces. For containerized workflows, consider using remote Docker hosts or cloud-based development environments.

Testing Your Own Applications

To check whether an application works under ADL:

  1. Install it through your distribution's package manager (apt install <package>).
  2. Launch it from the terminal to see any error output.
  3. Common failure modes to watch for:
    • "Operation not permitted" errors indicate missing kernel capabilities.
    • Segmentation faults on launch may indicate GPU or architecture issues.
    • Extremely slow startup usually means the application exceeds available resources.
  4. If an application fails, search for a lightweight alternative in the same category.