AND WE HAVE INPUT. No app was necessary, all that's needed is to change the group for /dev/input/eventX from video to input, before you try booting into CM (Cyanogenmod). You will also have to modify the init.rc file to start android serviceshere is my modified init.rc file (from Nexus 5) for reference.

This was tested on Alpha 14 on the Nexus 5 but it should still work on other versions and other phones.

1. Modify init.rc to start android services at boot time. (only needed to be done once) / If you're copying my modifed init.rc file then it goes in the root directory.
2. Restart
3. In terminal navigate to "/dev/input/"
4. run command "devel-su find . -name 'event*' -exec chown :input {} +" (this resets every time you restart the phone)
5. In the terminal navigate to "/system/bin/"
6. run command "kill -stop [pid of lipstick]; ./surfaceflinger &"
7. It should now boot into CM from within Sailfish

CAVEATS:

• Once you boot into CM from Sailfish, it's not always possible to get back into Sailfish. (Can do but only via ssh)
  
• If you do get back into Sailfish then you will NOT be able to boot back into CM, unless you restart the phone. Now possible providing you pause surfaceflinger and unpause lipstick, again only currently possible via SSH
  
• WiFi and Mobile Data will only work in CM if it's been turned in Sailfish before hand.
  
• You cannot call or text from within CM.

EDIT2: Found out how to start surfaceflinger properly setprop ctl.start surfaceflinger(but for some reason doesn't always work)
EDIT 3: Made it clear for those not knowing init.rc goes in the root directory.

does it mean it is possible to start apk from it??

all the android apps work when booted into the CM environment. I haven't flashed gapps to the rom so not sure if that will break things or make things more stable :P , I haven't tried installing new apps to it but it should work.

Just to be clear, the android apps DON'T run inside a card on Sailfish, but in CM.

you guys rock...but i am wondering if it is not possibile to come back to sfos without reboot, what sense does it make? or is it a wip solution? is there a gui or is all by terminal? can you make some video for let ignorants like me understand the results? however really thanks, if you guys need support as donation,i am here

It is definitely a WIP, CM isn't stable so there's still lots to do to get Android apps working in Sailfish. But now that input works it makes it a lot easier eg. to get adb access to the device, and to know input still works in Sailfish with the changes

and btw I flashed gapps, and they installed, but when I tried to login CM didn't detect that it already had WiFi access and then Surfaceflinger crashed.

TODO

• Fix the Android errors to get it stable
• Find a way to switch between CM and Sailfish (on a permanent basis)
• sort out Wifi and Mobile network connection in CM connect it to Sailfish
• Probably more stuff, and eventually get the Android apps in an app cover

EDIT: Here is a file for the logcat output in case any of you know how to fix the errors logcat dump

Are you using namespaces to isolate CM from Sailfish? They should help you to avoid problems with running the two OSs simultaneously.

I am not doing that, but probably should, but have no idea how. It feels like alien dalvik does it though.

The 3 system calls for manipulating namespaces are clone(2), setns(2) and unshare(2). Have a read through the namespaces(7) man page I linked to above, the man pages for those 3 system calls and also the pid_namespaces(7) and user_namespaces(7) man pages.

I'll look into it, but is this for aesthetic reasons visually splitting CM and Sailfish in top, or is it also for technical reasons, making it more stable.

Technical reasons. The reasons for why you can't get back into Sailfish after booting CM aren't 100% clear but if resources aren't properly isolated, I would guess that there is almost certainly some leakage going on there, where CM is overwriting/changing some in-memory OS resource provided by Sailfish. What you're doing is running one OS inside another but both OSs share the same kernel. This is essentially OS-level virtualisation and existing solutions such as LXC make extensive use of namespaces to ensure that the guest OS is properly isolated from the host OS, mainly for security purposes but it also helps to ensure correct behaviour.