[Feature Request]: Add support for Android / Termux (X11 & Wayland)

[GourangaDasSamrat]

Body

What are you proposing?

I am proposing first-class (or even experimental) support for compiling and running Zed on Android / Termux environments using X11/Wayland backends.

Specifically, this means enabling Zed (and its underlying UI framework, GPUI) to compile successfully targeting aarch64-linux-android (via standard X11 or Wayland display servers running on Android, like Termux-X11).

---

Why does this matter?

• Highly Powerful Mobile Hardware: Modern Android tablets and flagship phones (especially ARM64) are incredibly fast. Many developers are shifting toward highly portable, lightweight coding setups using Termux.
• The Ultimate Lightweight Editor: Currently, the only viable GUI editor in Termux is Code-OSS (VS Code), which runs on Electron. It is extremely heavy, sluggish, and consumes massive amounts of battery and RAM on mobile devices.
• Perfect Match for Rust: Since Zed is written natively in Rust and uses GPU acceleration, it would be the absolute ultimate IDE/editor for resource-constrained, portable ARM64 devices. It would offer a buttery-smooth experience that Electron simply cannot match.

---

Are there any examples or context?

• Alacritty Works Flawlessly: Terminal emulators like Alacritty (which Zed actually forks for its built-in terminal) now run exceptionally well in native Termux X11/Wayland environments. This shows that GPU-accelerated Rust apps are fully viable here.
• Termux Community Discussion: The Termux packaging community has been trying to port Zed for over two years but is currently blocked by deep compilation issues. You can find the main discussion here: termux-packages#21406

---

Possible approach

Based on the blockers identified by the Termux maintainers, a few key areas need to be addressed:

1. Relax target checks in GPUI: Allow GPUI to compile and run using the Linux X11/Wayland rendering pipeline even when the target OS is detected as android (as Termux users run standard X11/Wayland servers on device).
2. Shared Memory (SHM) Fallbacks: Address crates like rustix or wayland-cursor where target_os = "android" completely disables shared memory features (shm_open, shm_unlink). Since Android's Bionic libc restricts standard SHM, we need a fallback mechanism for the rendering loop.
3. NDK / Cranelift Compatibility: Ensure core compiler dependencies (such as cranelift-codegen or aws-lc-sys) can compile successfully under the Android NDK toolchain without triggering compiler segfaults.