by looking at the android sources in "development/tools/emulator" i found that goldfish (the android emulator version which is run by qemu - i don't know if it is actually called goldfish) communicates via a so called "qemud bridge" with a renderer application on the host. calls from the egl/opengl(es), and so on libs are passed through the qemud bridge and executed on the host. i think it should be possible to run goldfish (i am just gonna call it that) inside a chroot and the renderer application on the device, it should just be a matter of compiling everything and hacking around with qemud and the renderer application... but who knows, i might be wrong... i might try it eventually, any help is greatly appreciated

also chompers chroid seems to do just that...

this should work on the n9 with a kernel built with all the required android patches.. don't know about the state of the n900s kernel though

How much is to be built?

That is basically what I did for my build (detailed on page 7 a little), I built the Goldfish ICS (I had to remove the EGL and OpenGL libs because they interfered with the OS) and had a kernel Open() hook so it would open the right /dev/fb* device (I know I should have patched the source but I wasn't really bothered). At the end my opengl shims were based on that bridge used for Host GPU rendering on the Android SDK VMs, but I think I no longer have the source for those shims.

I should still have the kernel sources around, they would be a very good start if someone's interested in working on this, I can Github them I think I have the script for modding the final ICS build and the scripts for running it on Maemo + a couple other things, but cannot recall what I kept or threw away. I think I can dig around the internet for a patch I used to include PulseAudio support to android sound output but I remember (seem to recall??) it had to be extensively modded to run on the Maemo PulseAudio (could be wrong though, this was a while back).

I remember there was a bug on my kernel though, when the device turned on with the charger if it booted my kernel it would not power off on Power button press/charger removal and the battery had to be extracted... other than that I think it even worked with CSSU Thumb (I found no issues).

It's based on KP51r1 and again, I can upload all I have if someone wants to continue/finish development

You should upload it somewhere in case someday someone decides to take this up. Or even better - with the whole procedure to be able to apply this to kp52

pablocrossa: did your try bring up the whole Android UI including the launcher? Or only a single app?

What if we simply managed to build only the Dalvik VM. Would it be enough to run the Android apps (maybe not all but some)? If not all, what else would be needed? Android experts' opinion appreciated

Right, I'm getting all the sources together, just very busy with Uni work as of late

I had the entire Android subsystem running, hence the huge system load. The entire Android UI was running in a window on the desktop, similar to EasyDebian with Xephyr.

If the Dalvik VM is ported As-is (i.e. compiled against glibc) all Java-based apps will work, but no apps that use the NDK will work at all; for that some fancy symbol conversion like what libhybris does is needed. The problem is quite complex though, as all Android APIs are different to a standard Linux install:

• Sound subsystem is entirely different
• Graphics subsystem is entirely different, including windowing etc
• HW interaction libraries are entirely different
• etc etc

Basically all the HAL is different plus they use a different libc... it is a monumental piece of work to just port the thousands of lines of code of Dalvik VM (like what Alien Dalvik did).

As such it's probably easier to start porting the entire subsystem using the method I used (which wasn't much work TBH, just quite a bit of time and patience) and just start shimming everything little by little until Dalvik VM doesn't depend on the Android subsystem for anything important anymore; this allows you to test as you go along without blindly writing API shims and not seeing a result.

At this point it becomes easier to investigate libhybris and to adapt previous shims and compile the Dalvik VM using libhybris' cool shims (this will be a shim party...) and start replacing all functionality that ties it to the system (i.e. the way Zygote listens to an event to spawn a new VM instead of launching with command line parameters) and at that point you have a fully bespoke system working perfectly well, just like Alien Dalvik effectively, which only requires bug fixing.

All this is a colossal amount of work to get through, I will upload my code and let anyone interested in dealing with the low-RAM N900 to continue, I was going to develop this on a Desktop on my spare time but as of late I have enough projects, Uni and personal, to keep me from investing a proper amount of time into this.

Hope this essay is helpful for someone :P

EDIT: Also libhybris removes dependencies on the Android kernel drivers AFAIK (haven't really played around with it yet), which means that the final solution could be placed in extras as a deb without a special kernel or anything

And would we be able to launch the Dalvik VM from chroot? Then it'd link against the Android libs.

Yep, you just need the Android kernel interfaces (i.e. binder and ashmem) baked in or they will refuse to work That was what I had going, you only had to launch it by sending a specific Android subsystem message through a system similar to dbus (as far as I recall) to get it to launch the new App, there's no calling it from the command line; the apps crashed instantly but they were launching :P

Bump...
Any will to revive this project?

android in chroot
nitdroid
and the like
I think we should always keep half alive...
But...
with Leste on the horizon ..
anbox is what we should work on then.
Ubports for example is doing just that.
Perhaps when Leste is prime time , asking some questions of UT devels is in our best interests...
heck asking UT devels now ...may assist us further and faster with Leste as well.