It is a nice little hacking project. However, it is not built on top of the Kernel (which would be possible using e.g. something like ljsyscall). A look over a

It is a nice little hacking project. However, it is not built on top of the Kernel (which would be possible using e.g. something like ljsyscall). A look over at LuaJIT and its FFI would probably also be nice in the context of this project. However, it is probably deemed to be a little pet project forever. It does away with about everything that Android provides, including the developer APIs that are often implemented in a proprietary way the closer you get to the driver layer. The "Android without cumbersome Java and NDK" (from another comment) is - arguably - not an Android at all. It is a Linux kernel and the glibc, with lots of the hardware not accessible. I've been going through a remotely similar experience when working on and with the Koreader project (http://github.com/koreader/koreader http://github.com/koreader/koreader, a document/ebook reader software aimed at e-ink devices, which often come with not much beside the kernel and glibc, plus a framebuffer to play on) and it takes some major design effort to create a proper event/GUI framework. Which we did in the Koreader project using Lua, too - it's just so nice a Language to prototype with. For Android - a platform we support for devices - we went via NDK (only a small wrapper, https://github.com/koreader/android-luajit-launcher https://github.com/koreader/android-luajit-launcher). Though we have an SDL (1&2) backend, too, in addition to a purely Kernel framebuffer/input API oriented backend. Maybe worth a look, though also maybe an overwhelming amount of code to begin with.