[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2euvupwy0oubb":3},{"code":4,"message":5,"data":6,"timestamp":26},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":22,"homepage":23,"updated_at":24,"history":25},"reveny\u002FAndroid-Compatibility-Layer",21,"A translation layer for Android on Linux. Run Android Apps and Games on Linux","Java",51,8,13,4,[],"Run Android APKs directly on Wayland Linux without a full Android container, aimed at desktop gamers and tinkerers.","ACL is an early-stage way to run APKs on a Linux desktop without booting a full Android image. It avoids a container and emulates as little as possible, but app compatibility is explicitly very limited today, so treat it as something to evaluate rather than a daily driver.\n\n## The problem\n\nSuppose you want to run one Android app or game on your Linux desktop. The usual options involve starting a full Android image in Waydroid or Anbox and waiting for it to boot, or relying on a native bridge for ARM code. ACL instead takes an APK path and launches it directly. The Java\u002FKotlin side is executed by an x86-64 ART build, and ARM64 native libraries are either translated ahead of time by LLVM or run through JIT. The result is a host-rendered Wayland window rather than an emulated device screen.\n\n## What's different\n\nACL's distinguishing choice is to reimplement the Android framework on Linux instead of virtualizing it. Windows go through Wayland, graphics through Vulkan or GLES on the host GPU, text through FreeType and HarfBuzz, storage through SQLite, and audio through PipeWire. Because most Android games are dominated by native code, the author presents AOT translation to x86-64 as the performance argument: no ARM-to-x86 emulation on hot paths and direct host GPU access.\n\nThe trade-off is sharp and documented by the author. According to the [README's missing-features list](https:\u002F\u002Fgithub.com\u002Freveny\u002FAndroid-Compatibility-Layer\u002Fblob\u002Fmain\u002FREADME.md), ACL lacks SystemUI, binder\u002FIPC, rotation, camera, sensors, GPS, telephony, Bluetooth, NFC, vibration, WebView, MediaCodec, hardware video decode, 32-bit ARM support, multi-window, and a permission UI. The author also warns that LLVM sometimes crashes on large libraries and says to expect bugs. The architecture buys a leaner runtime at the cost of most platform services that ordinary apps assume.\n\n## Who should try it\n\nThe best fit is someone with an x86-64 Wayland desktop and a specific, mostly native Android game or simple app they want to try without a full container, who is comfortable [filing GitHub issues](https:\u002F\u002Fgithub.com\u002Freveny\u002FAndroid-Compatibility-Layer\u002Fissues) when it fails. A poor fit is anyone who needs everyday essentials: WebView-heavy apps, camera or location features, 32-bit ARM APKs, or a permission dialog. Those are documented gaps, not bugs that may disappear with a flag, so they should shape expectations before downloading anything.\n\n## Requirements and limitations\n\nACL requires x86-64 Linux with Wayland — X11 is not supported — and a Vulkan or OpenGL ES driver. The release bundle is the low-friction path: extract the tarball and run `bin\u002Facl myapp.apk`, which bundles the Android runtime, framework jar, resources, fonts and linker. Building from source is much heavier: clang, CMake 3.28+, Ninja, LLVM 19+ with headers, plus FreeType, HarfBuzz, SQLite, image libraries, Wayland and libxkbcommon, with a setup script that clones a reduced AOSP manifest and builds host ART.\n\nSandboxing uses seccomp, Landlock, and private PID and network namespaces; network access is gated behind `--network`, and `--no-sandbox` is explicitly discouraged for untrusted apps. The author's warning that LLVM translation can crash on large libraries is the limitation most likely to block real games. Install state lives under `~\u002F.local\u002Fshare\u002Facl` by default, and `--uninstall` forgets a package and deletes its data; whether that is enough depends on what the app stores.\n\n## HotRepo's take\n\nHotRepo began tracking this repository on 2026-10-24 and recorded it at #23 on the java NEW-REPOSITORY board with 52 total stars on 2026-10-25. That is a snapshot on a new-project list, not an overall Trending rank or a daily growth figure, and there is not enough comparable history to judge whether interest will persist. Check the documented feature gaps and open issues against the one app you care about before spending a build or a download on it.",{"slug":19,"name":20},"devops","DevOps & Self-hosting",[],"MIT",null,"2026-10-25T03:19:45Z",[],1792915074]