reveny/Android-Compatibility-Layer

ACL 提供了一种在 Linux 桌面上直接运行 APK、而不必启动完整 Android 镜像的早期方案。它不用容器、尽量少做模拟，但作者明确说当前应用支持非常有限，所以更适合当作一次可评估的尝试，而不是日常主力工具。

解决什么问题

假设你只想在 Linux 桌面上跑某一个 Android 应用或游戏。常见做法是在 Waydroid 或 Anbox 里启动完整的 Android 镜像、等它开机，或者依赖 ARM 原生桥接。ACL 改成从命令行直接给一个 APK 路径：Java/Kotlin 部分由 x86-64 的 ART 执行，ARM64 原生库要么由 LLVM 提前翻译，要么通过 JIT 运行。最终得到的是一个由 Wayland 托管渲染的窗口，而不是模拟出来的设备屏幕。

有什么不同

ACL 的核心选择是把 Android framework 重新实现到 Linux 上，而不是虚拟化整个系统。窗口走 Wayland，图形通过宿主机 GPU 上的 Vulkan 或 GLES，文字用 FreeType 和 HarfBuzz，存储用 SQLite，音频用 PipeWire。由于多数 Android 游戏以原生代码为主，作者把 AOT 翻译到 x86-64 当作性能论据：热路径上不做 ARM 到 x86 的模拟，图形直接走宿主机 GPU。

代价也很直接，而且作者自己列了出来。按 README 的缺失功能清单，ACL 目前缺少 SystemUI、binder/IPC、旋转、摄像头、传感器、GPS、电话、蓝牙、NFC、振动、WebView、MediaCodec、硬件视频解码、32 位 ARM 支持、多窗口和权限界面。作者还提醒 LLVM 在大型库上偶尔会崩溃，并说明项目仍处早期、要做好遇到 bug 的准备。这套架构换来了更轻的运行时，却舍弃了普通应用习以为常的大部分平台服务。

谁值得试

比较适合的是这样一类人：使用 x86-64 Wayland 桌面，心里有一个以原生代码为主的具体 Android 游戏或简单应用，想在不搭完整 Android 容器的前提下试一试，并且遇到失败时愿意去 GitHub 提 issue。不太适合的是需要日常功能的人：依赖 WebView 的应用、摄像头或定位功能、32 位 ARM APK，或者需要权限弹窗。这些是文档写明的缺口，不是换个参数就可能消失的小毛病，下载之前就该据此调整预期。

使用条件与边界

ACL 要求 x86-64 Linux 加 Wayland——不支持 X11——并且需要 Vulkan 或 OpenGL ES 驱动。发布包是省事的路子：解压后运行 bin/acl myapp.apk，里面已经带了 Android 运行时、framework jar、资源、字体和链接器。从源码构建则重得多：需要 clang、CMake 3.28+、Ninja、带头文件的 LLVM 19+，以及 FreeType、HarfBuzz、SQLite、图像库、Wayland 和 libxkbcommon；安装脚本会拉取精简版 AOSP manifest 并编译宿主机 ART。

项目通过 seccomp、Landlock、私有 PID 与网络命名空间提供隔离；网络访问要显式加 --network，作者也明确不建议对不可信应用加 --no-sandbox。“LLVM 翻译大型库时可能崩溃”是作者自己写出的限制，也最可能挡住真正想跑的游戏。安装状态默认放在 ~/.local/share/acl，--uninstall 会删除该包及其数据；这是否让你放心，取决于应用存了什么数据。

HotRepo 点评

HotRepo 从 2026-10-24 开始追踪这个仓库，2026-10-25 记录到它在 java 新项目榜上以 52 个总 star 排第 23。这是新项目榜上的一个快照，不是总榜排名，也不是单日增长数据；可比较的历史太少，无法判断关注度能否持续。现阶段更实际的做法是：先拿你真正关心的那个应用，对照文档写明的功能缺口和 issue 列表，再决定要不要花时间构建或下载。