Architecture: Native vs Proot vs Chroot
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
Setting up a Linux environment on Android via Termux involves choosing between three primary architectural approaches: Native, PRoot, and Chroot. Each method offers a different balance between ease of use, performance, system isolation, and compatibility with standard Linux applications. This architecture page outlines the technical differences, hardware interaction models, and requirements for each environment within the Termux-Desktops project.
The choice of architecture dictates how the guest Linux environment interacts with the Android kernel and hardware, specifically regarding library linking (Glibc vs. Bionic) and graphical rendering pipelines (Zink, Turnip, VirGL).
Sources: README.md:14-25, Documentation/terminology.md:4-15
Architectural Comparison
The project classifies environments based on their isolation method and requirement for elevated privileges.
| Feature | Native | PRoot | Chroot |
|---|---|---|---|
| Root Required | No | No | Yes |
| Isolation | None (Direct) | User-space (System call interception) | Directory Jail (Filesystem isolation) |
| Performance | High (Native) | Moderate (Emulation overhead) | High (Native) |
| C Library | Bionic | Glibc | Glibc |
| Setup Complexity | Simple | Moderate | Advanced |
Sources: README.md:112-118, Documentation/terminology.md:4-15
Architectural Flow of Environments
The following diagram illustrates how each environment interfaces with the Android Host and Kernel.
The diagram shows that Native Termux runs directly atop the Android libraries, while PRoot uses a translation layer for system calls, and Chroot utilizes kernel-level directory isolation.
Sources: Documentation/terminology.md:4-15, Documentation/chroot/ubuntu_chroot.md:47-65
Termux Native
Termux Native refers to running Linux utilities and Desktop Environments (DE) directly within the Termux application without virtualization. It uses the Bionic C library (Android's standard) rather than the Glibc used by traditional Linux distributions.
Key Characteristics
- Performance: Offers the best performance as there is no interception of system calls.
- Compatibility: Limited to packages explicitly compiled for Termux (Bionic). Standard Linux binaries usually fail unless a
glibc-runneris used. - Hardware Access: Direct access to hardware acceleration via native packages like
mesa-vulkan-icd-freedreno-dri3.
Sources: Documentation/native/termux_native.md:10-38, Documentation/terminology.md:21-31
PRoot (User-space Isolation)
PRoot is a user-space implementation of chroot, mount --bind, and binfmt_misc. It allows users to run full Linux distributions (Debian, Ubuntu, Arch, etc.) without needing root access.
Execution Logic
PRoot functions by intercepting system calls from the guest applications and translating them into calls the host Android kernel understands. This allows the guest to believe it is running in a standard root directory (e.g., /) while actually residing in a Termux subdirectory.
Components
- proot-distro: The management utility used to install and log into various distributions.
- Glibc: Guest distributions run their native Glibc libraries, enabling compatibility with standard Linux
.debor.rpmpackages.
Sources: README.md:95-103, Documentation/terminology.md:10-12, Documentation/proot/arch_proot.md:20-25
Chroot (Directory Jail)
Chroot (Change Root) is a native Unix command that changes the apparent root directory for current processes. In Android, this requires root privileges and typically involves mounting system partitions.
System Integration
Chroot environments achieve high performance by bind-mounting host directories directly into the guest environment.
- Bind Mounts: Essential directories like
/dev,/sys, and/procare mounted into the Chroot path. - Startup Script Logic:
- Remount
/datawithsuidsupport. - Bind host
/dev,/sys,/procto guest paths. - Mount
tmpfsfor/dev/shm(required for Electron apps). - Execute
busybox chrootinto the target directory.
- Remount
Sources: Documentation/chroot/ubuntu_chroot.md:47-65, Documentation/terminology.md:6-8
This sequence shows the privileged setup required to initialize a Chroot jail.
Sources: Documentation/chroot/ubuntu_chroot.md:47-75
Graphical and Acceleration Architecture
All three architectures utilize Termux:X11 for GUI rendering, but the data flow for hardware acceleration varies.
Rendering Pathways
- Zink + Turnip: Translates OpenGL calls to Vulkan (Zink) and uses the Turnip driver for Adreno GPUs. This is the most efficient pathway for hardware acceleration.
- VirGL: A virtual OpenGL renderer used primarily in PRoot/Chroot when direct GPU access is restricted. It uses a
virgl_test_serverin Termux to bridge calls. - LLVMpipe: Software rasterizer that uses the CPU for rendering; used as a fallback but offers the lowest performance.
Acceleration Implementation Table
| Architecture | Primary Accelerator | Command / Variable |
|---|---|---|
| Native | Turnip (Dri3) | MESA_LOADER_DRIVER_OVERRIDE=zink |
| PRoot | VirGL / Zink | GALLIUM_DRIVER=virpipe |
| Chroot | Direct Turnip | TU_DEBUG=noconform |
Sources: Documentation/HardwareAcceleration.md:18-45, Documentation/terminology.md:38-60, Documentation/HardwareAcceleration.md:130-136
Summary
The choice between Native, PRoot, and Chroot is a trade-off between privilege and performance. Termux Native is the leanest but most restricted. PRoot provides a full Linux experience for non-rooted users at the cost of moderate performance overhead. Chroot provides maximum performance and system integration but requires a rooted device and complex manual configuration of mount points and permissions. Regardless of the architecture, the integration of translation layers like Zink and Turnip is critical for achieving usable desktop performance on mobile hardware.
Sources: README.md:105-110, Documentation/terminology.md:85-95