Android (ARM64) Support Request — e4mc & World Host Compatibility on Zalith Launcher 2

Hi everyone — this issue is directed to both the e4mc team, World Host (Gaming32), and the Zalith Launcher 2 dev, as this is a collaborative problem that affects all three projects and the wider Android Minecraft Java community. The Problem: Currently, both e4mc and World Host do not function on Android (specifically Zalith Launcher 2) due to several technical barriers. First, the native libraries these mods rely on — such as Netty bindings and OpenSSL — are compiled exclusively for x86_64 and are not compatible with ARM64 (aarch64), which is the architecture used by virtually all modern Android devices. Second, the Pojav-based JRE used by Zalith Launcher 2 and similar Android Java launchers restricts certain deep reflection calls, raw socket behaviors, and JNI operations that these mods depend on. Third, Android's network stack — especially under carrier-grade NAT on mobile data connections — makes direct peer-to-peer connections extremely difficult without a proper relay or STUN/TURN implementation designed with Android in mind. The result is that Android players either see the mod crash on load, fail to generate a shareable link, or get stuck with errors like "room closed" or "network unstable" even when the mod partially initializes. What Needs To Be Done (Technical): For e4mc & World Host devs — the most impactful fix would be to introduce a pure Java fallback code path that activates when native libraries are unavailable or when an Android/Pojav environment is detected, like so: if (System.getProperty("java.vm.name").contains("Android") || System.getenv("POJAV_ENVIRON") != null) { useJavaSocketFallback(); // Pure Java, ARM64 safe } else { useNativeLib(); // Original x86_64 path } Additionally, cross-compiling the native dependencies for ARM64 using Android NDK would allow the full feature set to work without any fallback. Even an experimental ARM64 branch would be a massive step forward. For Zalith Launcher 2 dev — the most helpful approach would be to implement a networking compatibility shim layer similar to how PojavLauncher handles LWJGL for rendering, but targeting networking mod dependencies. This would involve patching the JRE layer to intercept and redirect native lib calls to ARM64-compatible alternatives, and bundling ARM64 builds of common mod networking dependencies like Netty directly inside the launcher so mods don't need to ship their own. This is the same general concept as how Wine allows Windows apps to run on Linux — a translation/compatibility layer sitting between the mod and the underlying system. Collaboration Suggestion: The most efficient path forward is direct collaboration between all three teams. Both e4mc and World Host are open source, and Zalith Launcher 2 has an active dev community. A joint effort — whether through a pull request, a shared testing branch, or even just an open discussion thread — would benefit everyone. The Zalith dev can provide an Android test environment and insights into the Pojav JRE limitations, while the e4mc and World Host devs can guide the correct integration points within their mod architecture. Together, a working Android implementation is absolutely achievable. e4mc repo: https://github.com/e4mc-team/e4mc World Host repo: https://github.com/Gaming32/world-host Zalith Launcher 2: [link] Why This Matters — Community Impact: Android Minecraft Java players are one of the most underserved audiences in the entire modding ecosystem. Launchers like Zalith, PojavLauncher, and FCL have collectively hundreds of thousands of downloads, with a large portion of their users coming from developing countries where Android is the primary — sometimes only — gaming device available. Features like e4mc and World Host are consistently among the most requested by this community, precisely because mobile network environments make traditional port forwarding impossible, and the built-in multiplayer options in Android launchers remain unstable or limited. Even a partial implementation, an experimental opt-in build, or just an official acknowledgment that Android support is being explored would be celebrated by thousands of players. Beyond that, supporting Android opens both projects up to a massive new wave of contributors, testers, and community members who are eager to help but have been blocked by this exact compatibility wall for a long time. This is a real opportunity to make a meaningful difference for a huge and growing part of the Minecraft Java community that has largely been left behind — and with collaboration between these three teams, it is absolutely within reach. Thank you so much for reading and for considering this. I and many others in the community are ready and willing to help test, report bugs, and support in any way we can. 🙏