"LXC requires at least linux kernel 3.14 to be secure."

secure means?

"I don't know if someone manage to port specific N900 code to this kernel version [...]"

Yes.

"And as far as I know, Android kernel features are not integrated in the linux kernel yet."

That's the funny kernel stuff I'm mentioning above.

"[...] is not a solution to run Android [...]"

Running (or booting) is not the good word. To put it better, let's use: "running" & "booting"

"And as far as I know, Android kernel features are not integrated in the linux kernel yet."

For sure, Android "features" (or most of them) are not in the vannila kernel (aka kernel.org). Android has it's own git & everything, hosted by google. <- Android git is a place from where we are going to take neccessary patches (right?).

@liar, lexik:

So only the modules as written here are a must. What happens some of them aren't in the kernel? Segfaults?

Harmattan can run the Nitdroid dual-boot kernel with those options enabled. Is there any reason why Fremantle can't?

And, what's the recommended way to contribute at this early, kernel-based stage?

I was actually doing this QUITE a while back (hence this: http://talk.maemo.org/showthread.php?t=90175 )

I got to a point where Android ICS compiled for the goldfish emulator (with some changes) got to the lock screen but apps didn't work; I ended up tracking this down to environmental variables exported on the Android chroot not being preserved.

WHAT I DID:

1. Make a patch between NITdroid kernel and Powerkernel 51r1
2. Apply relevant sections to the drivers and generally all around (I do have the sources hiding about and will post them if requested).
3. Create a kernel driver for input on Android (mine was terrible, just the TS NITdroid driver compiled with "android" termination on the name so I could exclude from Maemo any input driver finishing in "ndroid" and ignore the standart one on Android).
4. Create a GUI that reads the FB from vfb.ko
5. Create a bunch of scripts that handled different images etc.
6. Create tools for openning and closing apps from Maemo (which I could do, they just crashed instantly).
7. Start mapping SurfaceFlinger (partial), OpenGL ES (done) and AudioFlinger (only output) through black magic, shims and unix domain sockets to EGL, OpenGL compiled on the N900 against GLIBC and PulseAudio.

PROBLEMS:

1. It didn't work because of the environmental variables thing (I believe android shares a handle to ashmem as an environmental variable and if that isn't present I can see the throuble).
2. The thing got the device up to 600MB of memory usage at which point it was sooooooo slow even my scripts to tickle the watchdogs every 3 (or 5, cannot remember) seconds ago could not keep up.

It REALLY isn't usable on a device with such little RAM, even if you fix the bugs above, so I decided to wait on an x86 Ubuntu Phone with teh ramz

How exactly does Alien Dalvik work compared to chroot? They had android apps running on a N900 maybe four years ago when it was first demoed. It is in the wild now with the Sailfish, what have sailfish owners discovered? Isn't this a better direction for OSSing?
Was there ever a leak of the Alien Dalvik .deb?

Well AFAIK (and I really don't know, as I have not been able to examine functionality/a binary) Alien Dalvik runs the Dalvik VM through a medium similar to libhybris with it patched to use the native Linux systems (EGL instead of SurfaceFlinger, native GLIBC OpenGL, PulseAudio instead of AudioFlinger), wrap all component APIs (bluetooth, accelerometer, input) and system APIs (notifications, etc) into their corresponding Linux counterparts and that's about it; that way any Android app would be able to load and run integrated with the system without the entire Android OS running too.

This was what I wanted to get to eventually but I wanted to start with chroot, then chroot with shims to accomplish native behaviour and then translate those shims to libhybris shims, eventually lowering the dependency count so the entire Android system doesn't need to run in the background; it worked so slow on my phone, however, that I dropped development until I could afford something faster (in fact, I might continue it on my desktop in the hope an x86 phone arrives).

EDIT: And no, I believe there unfortunately never was a leak.

Very cool, can you taken anything from the work of IcedRobot?
https://wiki.debian.org/Java/DevJam/...kers#IcedRobot
http://www.jroller.com/neugens/entry...cing_icedrobot

It looks promising, specially the GNUdroid component (I haven't found any proper instructions in my 2-minute internet stroll), but what they are doing would let Java apps work, but not apps coded with the NDK (such as many OpenGL games); with libhybris you can pretty much get any app to work (how hard that is remains to be seen, haven't really given libhybris a good look yet) as you can wrap shared objects with it and obscure libraries shipped with working NDK code can be executed against a GLIBC/EGLIBC system.

lexik: do you have a final decision concerning this?

You guys might be interested in this:

http://forums.webosnation.com/androi...ide-webos.html
https://www.youtube.com/watch?v=VTXcJkCoJgM
https://www.youtube.com/watch?v=vyBJW3VGZ4A

It might be possible to port it to the N900.

After a brief look there it needs some patched uImage, so we'd need first to patch the kernel, once again. Or it might be simply an Android kernel.

lexik, if you're unable to do the kernel job on your own, maybe it's a good idea to ask the community for help?