My dream for Pyra Android would be too see a rooted Vanilla Android with the Xposed framework pre installed along with a specific Xposed Module for Pyra.
The Xposed module for Pyra would cover Pyra specific aspects such as defaulting to the hardware keyboard, Screen rotation settings, easy button configuration (choose Home / Back / recent apps buttons) etc.
Not sure how that would fit in to the above.
This sounds like a reasonable way to approach it, never heard of Xposed until you made me Google it
seems easier and better to ship than a dedicated 'Pyra app'. We have a way to communicate with the host from the VM so most of this is not difficult. That being said, I have zero experience with Xposed, so it might take some time to get it right.
That's not really all that bad. What it needs is bridged networking to the Pyra's Debian OS - at that point it's functioning Android in network connected tablet mode - which is very cool in itself. Android doesn't have to be a full phone instance to be usable.
I'd not want Android to hijack the phone hardware anyway, I'd rather use whatever pyra uses for calls.
Me too, I think I would like the Pyra OS to handle the calls, but I understand the reasons why others want to be able to do this from Android and, as such, I will try to get it working ASAP without some messy hack in place; if enough people want it I will make it a priority after basic HW support.
I wanted to drop this here FYI. Just found out about this:
https://conf.kde.org/en/akademy2015/public/events/198
I still think that your development, pablocrossa, is better because of several reasons, but still, this could be interesting to keep an eye on too.
I think your development is better, too as running Android applications on Linux is NOT the same thing with running Full Android Lollipop on Linux-Pyra. Also, we have small hopes for possible phone calls
I like compatibility layers but I'm not entirely fond of them, I would like an Android system that guarantees 100% app compatibility (or close to that) and that I can isolate in a secure manner (try to keep it from exploiting my Pyra OS).
Also as much as I would like this to be my development, really I'm just stitching other people's tools together, I will release a full list in the future but the real awesome people to thank are:
Linaro
Google
As soon as I have to do some more difficult GLES coding then I will take some merit
Saw that after getting the link above, seems to only support the data connection aspect only though, if it gets expanded it might be a reasonable framework to build a dialer on top.
Now, for my update:
Work is keeping me very busy so unfortunately I have not been able to look into this at all since the last update; I will try to continue ASAP and should be able to find time for it this week. If however by the end of the month I haven't had time to give it a look I will post my sources as is on Github (or a similar platform) and accept commits from other developers that can probably solve some issues better than I can.
I will try to work on this a little tomorrow and, if I get something done, I will get back to you. 3D acceleration is almost working so there's a change very soon it will be ready.
That's all for now folks
EDIT: I almost forgot, if the modem doesn't do any DMAs it can probably be passed-through to a VM no issue; if it does it will depend on the OMAP5 and Pyra architecture and if a SystemMMU exists between the modem and the RAM; if so it should be able to be passed-through too. Passing the modem through might be the easiest way to get full modem support on a VM (rather than hack a virtual modem and make in interface with the real one, which is a lot of work, might be done but it might be easier to start with a direct pass-through).
