Android 4.4/5.0 OOB?


Hi there, no little update here, just to let you all know my brother was visiting for a week and between him and work I haven't had any time to look at this; he leaves tomorrow so there might soon be another update, right now I'm debugging and fighting against errors on the goldfish pipe, might break through sooner rather than later :) or not... Will get back to you with some progress :)
 
Wow. New versions of Android in Pyra was just a dream for me. I hope you will be able to finish your work on Pyra ASAP when it comes!

Also, I want to ask a quick question. Will we be able to use Guest Android like it is on a normal smartphone?

Like getting root permissions?
 
Last edited by a moderator:
Hello, still very busy with work but a new update.

I am facing a black screen on the emulator and spammed error messages on the host console BUT Android is now booting in HW acceleration mode. It's still broken enough for the screen to be black but advanced enough for Android to boot and work (when you slide the lockscreen you get corresponding errors on the console regarding updates that are not happening). As soon as I find the issue a big chunk of the work will be done, only the replacement of the translator libraries with EGL+GLES equivalent ones is needed and all the tough work would be done. Will post a screenshot as soon as I get working screen updates on the HW acceleration.

Another less positive news is the upstream, less hacked and updated Qemu build has no modem and other Android-related hardware emulation; the feasibility and work needed to port the features over is unknown right now, but enough things will be working by the Pyra launch to have a usable Android build in a VM.

Wow. New versions of Android in Pyra was just a dream for me. I hope you will be able to finish your work on Pyra ASAP when it comes!

Also, I want to ask a quick question. Will we be able to use Guest Android like it is on a normal smartphone?

Like getting root permissions?
I hope it's ready when the Pyra arrives, it's a feature I'm looking forward to.

Probably three images will ship with this:

  1. A vanilla.
  2. A rooted.
  3. A rooted + RW /system partition.
So yes, you should be able to pick your poison and it should be usable like a 'normal' Android, as it IS a normal Android :)
 
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.
 
Another less positive news is the upstream, less hacked and updated Qemu build has no modem and other Android-related hardware emulation; the feasibility and work needed to port the features over is unknown right now, but enough things will be working by the Pyra launch to have a usable Android build in a VM.
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.
 
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 :)
 
Last edited by a moderator:
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 :)
This looks interesting: https://github.com/shashlik/android-telephony
 
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 :p

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).
 
Last edited by a moderator:
FWIW, I would also prefer Android not take over the 4G module.  Unless it is completely useless I will be using whatever we have for the Pyra to handle calls and messages.
 
FWIW, I would also prefer Android not take over the 4G module.  Unless it is completely useless I will be using whatever we have for the Pyra to handle calls and messages.
Or at least have a way to lock Android away from taking it over. I plan to have multiple Android instances running in the background - it would suck if they all took over the phone hardware and couldn't be stopped.
 
FWIW, I would also prefer Android not take over the 4G module.  Unless it is completely useless I will be using whatever we have for the Pyra to handle calls and messages.
Or at least have a way to lock Android away from taking it over. I plan to have multiple Android instances running in the background - it would suck if they all took over the phone hardware and couldn't be stopped.
If one thing's for sure is that the modem approach (whatever that is) will be opt-in rather than opt-out. Probably a little GUI will allow you to select things at image build (such as root or Play store) together with settings for boot that can be changed at a later time (such as 3D acceleration, RW /system and Modem integration/passthrough/whatever approach is taken).

Progress:


Found the source of the error but not sure why it's happening; have patched the Android source so it no longer happens but still booting with a black screen, I need to look more into it. As soon as I understand the problem this should make a leap forward and the basics will be covered.

That being said work is keeping me very busy and I'm unable to put the time needed to make this project advance quickly. I'm in the process of compiling in-depth instructions and patches of what I've done and GITing it all, so anyone else can help contribute probably better than I ever could. It will take me some time though.

I will continue to work on this, I am making progress, just not as much as I could otherwise. I still think 3D acceleration is very close to working in a stable manner :)
 
Hi there

I had some time to work on this over the weekend and decided to temporarily switch my approach; I'm now making the official Android emulator (based on the ancient Qemu with backports...) build on ARM.

I have a build optimised for a Cortex-A15 with FPU+NEON, using the TCG (read: no CPU acceleration) and the host OpenGL libraries (read: GPU acceleration on desktop GL 2, not GLES devices), and soon I will have backported the ARM KVM support introduced in 1.5.0 from version 1.7.0 (some structures within the emulator code align with 1.7.0, so that's where I'm ripping the code out from), which includes GIC support.

I can't get Android to boot because, with GPU acceleration disabled and after waiting 2mins (the emulator window opens with the right skin etc), I still get a black screen. I suspect it's more due to the fact I'm running TCG on TCG on a 2.4GHz Core2Duo, which means the resulting emulator is probably too slow to get anywhere anytime soon (probably about 1% of the speed of the actual CPU AKA not usable at all). I can connect through Telnet though.

This is a call for testers, so if you:

  • Have a Cortex-A15 device
  • Have support for NEON and FPU
  • Can run an X server on it (even through XVNC or whatever Android users have to do now)
  • Can run an Ubuntu 14.04 system (be it native or chroot)
And preferably have:

  • A KVM-enabled kernel (but testing in TCG mode would still help)
  • Mesa (so we can test the host rendering libs)
Please get back to me so I can send you the binary and Android 5.1 system images + boot script to test nothing is severely broken. Testing on both TCG and KVM mode would be fantastic, with additional testing against Mesa with the host rendering libraries being a huge help too. If KVM works and the host libraries are not broken then the only step missing is to re-write the translator's GLX code to use EGL and possible intercept some problematic OpenGLES calls that cannot be run native (not a GL expert myself really...) and a basic system would be ready to roll :)

Trashy? :)

Thank you all for the help
 
I would love to test it but the only thing I can do from this list above is running ubuntu :(


Good luck!
 
@pablocrossa, you should get into contact with @Grench so he can test on one of the first Pyra prototypes!

Sounds like a great idea, though I'm going to need some step-by step instructions and an idea of what conditions show success/failure - and a Prototype. (They don't exist yet.) BUT - this type of thing is exactly what I would like to help test.
 
Back
Top