Android 4.4/5.0 OOB?

[WizardStan]

Good to know! Maybe it can be used as a VM for Android then

Except for the lack of 3D acceleration as Notaz mentioned.

 

[pablocrossa]

It can only do ARM on ARM.

 
No, but it can layer in QEMU on an ARM VM... Fake X86 VM on ARM?

http://www.virtualopensystems.com/en/solutions/guides/kvm-on-arm/

What makes you think it's x86? KVM doesn't imply x86 at all.

Note that android is useless without 3d acceleration (recent versions won't even boot without 3d I think?), and 3d is real difficult to do on virtualization..

Is this demonstration any help?http://www.virtualopensystems.com/en/solutions/demos/vosyshmem-api-remoting/

No? The fact that someone managed to pull off a spinning cube on some platform (exynos?) doesn't mean we can do full blown android on OMAP5, especially knowing the usual breakage of SGX driver and all.

Hi, first post here

I don't have an OMAP5 board but I am fiddling around with the Android SDK source code (including the emulator); Google provide a 3D OpenGLES acceleration library that forwards the calls to the host under their Qemu-based emulator. Under Linux it already supports KVM.

Putting this together, with some modding (as the host render is probably an OpenGL context, but changing some of that to keep OpenGLES as OpenGLES shouldn't be too much trouble... hopefully) it makes sense that a recompiled ARM version should be able to employ KVM acceleration to have near-native CPU performance and indirect OpenGLES 1.x and 2.x call forwarding to have near-native GPU performance, at which point one would have a very competent Android version installed as a VM.

Another great 'feature' of this approach is that Google support their emulator on all AOSP builds and, as such, when a new Android version is released, the changes would be as trivial as building the official emulator image with no further modding.

Put that together with a little "Notification-Clipboard forwarding" VM app, some optional built in Qemu constructs for file-system sharing and ADB with menu shortcuts to launch applications in the Android system, that really shouldn't be too much trouble to put together as everything but the bespoke VM app is documented, and you have a very competent, fast and portable solution that's trivially upgradeable with little effort.

NOTE: This is assuming their Qemu build isn't a minefield of x86 assembly or x86-dependent code, at which point more porting is needed... Again, haven't really given the emulator source a good look, will try to start this afternoon with a Qemu A15 emulated board and some OS on it .


PD: Anyone wanting to understand the advantages of this over Dalvik, it's just a different beast:

• This is a much more secure system; if you get malware or attacked in your Android environment it is isolated from the Pyra OS (I'm very much into secure systems).
• The Pyra host kernel doesn't need a meshf*ck of tweaked Android patches, like a modified process killer that will only affect Android processes (sorry, no other way to put it), which eases kernel portability with a lower system-specific patch list.

On the other hand:

• Alien Dalvik doesn't have a static memory cap like a KVM machine does (although AFAIK dynamic memory ballooning in KVM can be used to mitigate that somewhat).
• Alien Dalvik is less resource intensive and more integrated, the applications can feel native.
• Alien Dalvik shares the kernel with the Pyra OS, which allows tighter inter-process communication between the Alien Android ecosystem and the native Pyra OS (again, less security).

Just food for thought, excited about the Pyra and wanting to do something for the community myself now


EDIT: Upon further examination of the "android-emugl" libraries (at https://android.googlesource.com/platform/external/qemu/+/master/distrib/android-emugl/READMEwith quite a self explanatory name really) it appears that the encoding and decoding of GLES commands is independent from the GLES-to-GL layer, which could mean a potentially easier porting process

 

[edgex004]

It can only do ARM on ARM.

No, but it can layer in QEMU on an ARM VM... Fake X86 VM on ARM?

http://www.virtualopensystems.com/en/solutions/guides/kvm-on-arm/

What makes you think it's x86? KVM doesn't imply x86 at all.

Note that android is useless without 3d acceleration (recent versions won't even boot without 3d I think?), and 3d is real difficult to do on virtualization..

Is this demonstration any help?http://www.virtualopensystems.com/en/solutions/demos/vosyshmem-api-remoting/

No? The fact that someone managed to pull off a spinning cube on some platform (exynos?) doesn't mean we can do full blown android on OMAP5, especially knowing the usual breakage of SGX driver and all.

Hi, first post here


I don't have an OMAP5 board but I am fiddling around with the Android SDK source code (including the emulator); Google provide a 3D OpenGLES acceleration library that forwards the calls to the host under their Qemu-based emulator. Under Linux it already supports KVM.


Putting this together, with some modding (as the host render is probably an OpenGL context, but changing some of that to keep OpenGLES as OpenGLES shouldn't be too much trouble... hopefully) it makes sense that a recompiled ARM version should be able to employ KVM acceleration to have near-native CPU performance and indirect OpenGLES 1.x and 2.x call forwarding to have near-native GPU performance, at which point one would have a very competent Android version installed as a VM.


Another great 'feature' of this approach is that Google support their emulator on all AOSP builds and, as such, when a new Android version is released, the changes would be as trivial as building the official emulator image with no further modding.


Put that together with a little "Notification-Clipboard forwarding" VM app, some optional built in Qemu constructs for file-system sharing and ADB with menu shortcuts to launch applications in the Android system, that really shouldn't be too much trouble to put together as everything but the bespoke VM app is documented, and you have a very competent, fast and portable solution that's trivially upgradeable with little effort.


NOTE: This is assuming their Qemu build isn't a minefield of x86 assembly or x86-dependent code, at which point more porting is needed... Again, haven't really given the emulator source a good look, will try to start this afternoon with a Qemu A15 emulated board and some OS on it .


PD: Anyone wanting to understand the advantages of this over Dalvik, it's just a different beast:

• This is a much more secure system; if you get malware or attacked in your Android environment it is isolated from the Pyra OS (I'm very much into secure systems).
• The Pyra host kernel doesn't need a meshf*ck of tweaked Android patches, like a modified process killer that will only affect Android processes (sorry, no other way to put it), which eases kernel portability with a lower system-specific patch list.

On the other hand:

• Alien Dalvik doesn't have a static memory cap like a KVM machine does (although AFAIK dynamic memory ballooning in KVM can be used to mitigate that somewhat).
• Alien Dalvik is less resource intensive and more integrated, the applications can feel native.
• Alien Dalvik shares the kernel with the Pyra OS, which allows tighter inter-process communication between the Alien Android ecosystem and the native Pyra OS (again, less security).

Just food for thought, excited about the Pyra and wanting to do something for the community myself now

EDIT: Upon further examination of the "android-emugl" libraries (at https://android.googlesource.com/platform/external/qemu/+/master/distrib/android-emugl/READMEwith quite a self explanatory name really) it appears that the encoding and decoding of GLES commands is independent from the GLES-to-GL layer, which could mean a potentially easier porting process

You, sir, are a cool guy. I like what you are doing. Any way to easily access android apps lets me ditch my phone entirely.

 

[pablocrossa]

It can only do ARM on ARM.

No, but it can layer in QEMU on an ARM VM... Fake X86 VM on ARM?

http://www.virtualopensystems.com/en/solutions/guides/kvm-on-arm/

What makes you think it's x86? KVM doesn't imply x86 at all.

Note that android is useless without 3d acceleration (recent versions won't even boot without 3d I think?), and 3d is real difficult to do on virtualization..

Is this demonstration any help?http://www.virtualopensystems.com/en/solutions/demos/vosyshmem-api-remoting/

No? The fact that someone managed to pull off a spinning cube on some platform (exynos?) doesn't mean we can do full blown android on OMAP5, especially knowing the usual breakage of SGX driver and all.

Hi, first post here


I don't have an OMAP5 board but I am fiddling around with the Android SDK source code (including the emulator); Google provide a 3D OpenGLES acceleration library that forwards the calls to the host under their Qemu-based emulator. Under Linux it already supports KVM.


Putting this together, with some modding (as the host render is probably an OpenGL context, but changing some of that to keep OpenGLES as OpenGLES shouldn't be too much trouble... hopefully) it makes sense that a recompiled ARM version should be able to employ KVM acceleration to have near-native CPU performance and indirect OpenGLES 1.x and 2.x call forwarding to have near-native GPU performance, at which point one would have a very competent Android version installed as a VM.


Another great 'feature' of this approach is that Google support their emulator on all AOSP builds and, as such, when a new Android version is released, the changes would be as trivial as building the official emulator image with no further modding.


Put that together with a little "Notification-Clipboard forwarding" VM app, some optional built in Qemu constructs for file-system sharing and ADB with menu shortcuts to launch applications in the Android system, that really shouldn't be too much trouble to put together as everything but the bespoke VM app is documented, and you have a very competent, fast and portable solution that's trivially upgradeable with little effort.


NOTE: This is assuming their Qemu build isn't a minefield of x86 assembly or x86-dependent code, at which point more porting is needed... Again, haven't really given the emulator source a good look, will try to start this afternoon with a Qemu A15 emulated board and some OS on it .


PD: Anyone wanting to understand the advantages of this over Dalvik, it's just a different beast:

• This is a much more secure system; if you get malware or attacked in your Android environment it is isolated from the Pyra OS (I'm very much into secure systems).
• The Pyra host kernel doesn't need a meshf*ck of tweaked Android patches, like a modified process killer that will only affect Android processes (sorry, no other way to put it), which eases kernel portability with a lower system-specific patch list.

On the other hand:

• Alien Dalvik doesn't have a static memory cap like a KVM machine does (although AFAIK dynamic memory ballooning in KVM can be used to mitigate that somewhat).
• Alien Dalvik is less resource intensive and more integrated, the applications can feel native.
• Alien Dalvik shares the kernel with the Pyra OS, which allows tighter inter-process communication between the Alien Android ecosystem and the native Pyra OS (again, less security).

Just food for thought, excited about the Pyra and wanting to do something for the community myself now

EDIT: Upon further examination of the "android-emugl" libraries (at https://android.googlesource.com/platform/external/qemu/+/master/distrib/android-emugl/READMEwith quite a self explanatory name really) it appears that the encoding and decoding of GLES commands is independent from the GLES-to-GL layer, which could mean a potentially easier porting process

You, sir, are a cool guy. I like what you are doing. Any way to easily access android apps lets me ditch my phone entirely.

I'm on the same boat, thank the Pyra guys for designing such an awesome device

From additional documentation (https://android.googlesource.com/platform/external/qemu/+/master/distrib/android-emugl/DESIGN ):

1. 2 - The ability to use vendor-specific desktop EGL/GLES libraries is
   
2. important.
4. GPU vendors like NVidia, AMD or ARM all provide host versions of the
5. EGL/GLES libraries that emulate their respectivie embedded graphics
6. chipset.
8. The renderer library can be configured to use these instead of the
9. translator libraries provided with this project. This can be useful to
10. more accurately emulate the behaviour of specific devices.
12. Moreover, these vendor libraries typically expose vendor-specific
13. extensions that are not provided by the translator libraries. We cannot
14. expose them without modifying our code, but it's important to be able
15. to do so without too much pain.

A.K.A. No heavy porting needed, it *should* hook into the native EGL + GLES subsystem.


I am setting up an ARM VM to experiment with, will keep updating with anything.

 

[edgex004]

It can only do ARM on ARM.

No, but it can layer in QEMU on an ARM VM... Fake X86 VM on ARM?http://www.virtualopensystems.com/en/solutions/guides/kvm-on-arm/

What makes you think it's x86? KVM doesn't imply x86 at all.

Note that android is useless without 3d acceleration (recent versions won't even boot without 3d I think?), and 3d is real difficult to do on virtualization..

Is this demonstration any help?http://www.virtualopensystems.com/en/solutions/demos/vosyshmem-api-remoting/

No? The fact that someone managed to pull off a spinning cube on some platform (exynos?) doesn't mean we can do full blown android on OMAP5, especially knowing the usual breakage of SGX driver and all.

Hi, first post here

I don't have an OMAP5 board but I am fiddling around with the Android SDK source code (including the emulator); Google provide a 3D OpenGLES acceleration library that forwards the calls to the host under their Qemu-based emulator. Under Linux it already supports KVM.


Putting this together, with some modding (as the host render is probably an OpenGL context, but changing some of that to keep OpenGLES as OpenGLES shouldn't be too much trouble... hopefully) it makes sense that a recompiled ARM version should be able to employ KVM acceleration to have near-native CPU performance and indirect OpenGLES 1.x and 2.x call forwarding to have near-native GPU performance, at which point one would have a very competent Android version installed as a VM.


Another great 'feature' of this approach is that Google support their emulator on all AOSP builds and, as such, when a new Android version is released, the changes would be as trivial as building the official emulator image with no further modding.


Put that together with a little "Notification-Clipboard forwarding" VM app, some optional built in Qemu constructs for file-system sharing and ADB with menu shortcuts to launch applications in the Android system, that really shouldn't be too much trouble to put together as everything but the bespoke VM app is documented, and you have a very competent, fast and portable solution that's trivially upgradeable with little effort.


NOTE: This is assuming their Qemu build isn't a minefield of x86 assembly or x86-dependent code, at which point more porting is needed... Again, haven't really given the emulator source a good look, will try to start this afternoon with a Qemu A15 emulated board and some OS on it .


PD: Anyone wanting to understand the advantages of this over Dalvik, it's just a different beast:

• This is a much more secure system; if you get malware or attacked in your Android environment it is isolated from the Pyra OS (I'm very much into secure systems).
• The Pyra host kernel doesn't need a meshf*ck of tweaked Android patches, like a modified process killer that will only affect Android processes (sorry, no other way to put it), which eases kernel portability with a lower system-specific patch list.

On the other hand:

• Alien Dalvik doesn't have a static memory cap like a KVM machine does (although AFAIK dynamic memory ballooning in KVM can be used to mitigate that somewhat).
• Alien Dalvik is less resource intensive and more integrated, the applications can feel native.
• Alien Dalvik shares the kernel with the Pyra OS, which allows tighter inter-process communication between the Alien Android ecosystem and the native Pyra OS (again, less security).

Just food for thought, excited about the Pyra and wanting to do something for the community myself now

EDIT: Upon further examination of the "android-emugl" libraries (at https://android.googlesource.com/platform/external/qemu/+/master/distrib/android-emugl/READMEwith quite a self explanatory name really) it appears that the encoding and decoding of GLES commands is independent from the GLES-to-GL layer, which could mean a potentially easier porting process

You, sir, are a cool guy. I like what you are doing. Any way to easily access android apps lets me ditch my phone entirely.

I'm on the same boat, thank the Pyra guys for designing such an awesome device

From additional documentation (https://android.googlesource.com/platform/external/qemu/+/master/distrib/android-emugl/DESIGN ):

• 2 - The ability to use vendor-specific desktop EGL/GLES libraries is
• important.
• GPU vendors like NVidia, AMD or ARM all provide host versions of the
• EGL/GLES libraries that emulate their respectivie embedded graphics
• chipset.
• The renderer library can be configured to use these instead of the
• translator libraries provided with this project. This can be useful to
• more accurately emulate the behaviour of specific devices.
• Moreover, these vendor libraries typically expose vendor-specific
• extensions that are not provided by the translator libraries. We cannot
• expose them without modifying our code, but it's important to be able
• to do so without too much pain.

A.K.A. No heavy porting needed, it *should* hook into the native EGL + GLES subsystem.
I am setting up an ARM VM to experiment with, will keep updating with anything.

If you manage to make good progress, it might be a good idea to get you access to a dev board. I'd kick in a few dollars for that!

 

[Grench]

So - my dream of having:

Pyra running Debian acting as the host OS

Android as a VM client running on the Debian host for work stuff.

Android as a VM client running on the Debian host for personal stuff.

Android as a VM client running on the Debian host for games/suspect stuff.

That might be possible?

COOL.

 

[pablocrossa]

Hello again

I'm going to start this with an apology due to the nature of this massive post, I like explaining my ideas and this happens more often than not
Onto the business at hand:

I'm going to try to not do this daily (as to not contaminate this thread too much) but I though I'd post a little update and ideas others can comment on.
I'm going to outline the process I'm currently following, which will probably develop and change when issues arise.

What I've done:

• I've prepared a quick 14.04 armhf (like the Pyra OS) that boots under Qemu A15 emulation in system mode.
• I tried very quickly to build the emulator with their provided script but, as expected, it seems to want an Android-compatible toolchain and build environment.
• I have set up an Android build environment and am downloading the whole 5.1 branch; I have also downloaded the 'master' emulator branch.

What I'm yet to do:

• When the source and all build tools are ready I will check the emulator source is available (on the 5.1 branch) and I will build the whole downloaded branch.
  When done make sure the built image boots on the built emulator.

[*]After the AOSP is built I will dissect the build process to only build the emulator without the added cruft (the emulator includes the GL forwarding libs, or emuGL).

• Make sure the previously built image boots with the newly built emulator.

[*]I will figure out how to build the emuGL call forwarding layer against Mesa EGL backend.

• Make sure the previously built image boots with the new Mesa backend - some debug prints or builds might help.

[*]I will port all features needed from the custom emulator (fast pipe for GL forwarding, EGL context and emuGL) and integrate this with the mainline Qemu.

• Make sure the prebuilt image boots with the patched Qemu using the Mesa backend.
  This could be simpler in the long run and will be something I might try when the Android image is built, to boot it with stock Qemu (which frees us from most of the following steps).

If the stock Qemu doesn't work or is unfeasible for some reason:

• When the process to build the emulator is established I will dissect the build process for the entire toolchain, meaning the binaries used to build the emulator (rather than using the prebuilt binaries).
  Make sure the emulator builds with these binaries and it still boots the image.

[*]I will determine the required toolchain elements to build the emulator.

• Make sure the emulator builds when removing all other binaries in a 'new' Android build env.

[*]These compilers/linkers/whatever else is needed will then be built on the 14.04 armhf VM and any errors will be fixed.

• Make sure they build and try to build some simple tests that ship with the Android source somewhere... probably...

After a methodology to build a working emulator and all needed non-debian dependencies is established:

• Build the emulator with an ARM target and any errors will be fixed.
  If using the Android emu vs upstream Qemu:
  Build all needed non-debian dependencies with an ARM target and make sure they work.
• The configure script needs fixing as it doesn't accept an ARM arch.
• Need to make sure the KVM path is still active on ARM.

[*]Make sure the built emulator uses the KVM backend (even without acceleration, see more on reply to edgex004) and boots the emulator with Mesa EGL backend.

This could potentially provide a set of binaries that can be tested on a real ARM chip with both CPU and GPU acceleration. On that topic:

[REDACTED]

If you manage to make good progress, it might be a good idea to get you access to a dev board. I'd kick in a few dollars for that!

I've been looking around to see if Qemu would provide a capable enough A15 to simulate a (rough and slow) Pyra, but unfortunately it doesn't support the virtualisation extensions that ARM introduced and that are integral to this project; additionally forwarding OpenGLES from a Linux guest seems a rather convoluted and outdated process with very specific builds, which means I'm going to need to get some hardware.

HOWEVER:

I don't need an OMAP5 board for $$$, I found this:
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME/open-source-hardware
The A7 dual core on it supports virtualisation and its GPU supports GLES 1.1 and 2.0 (which are AFAIK the only versions the emulator forwards AND the Pyra supports, coincidence? I think not! ). I know the A20 isn't perfect for Linux or modern kernels but hopefully the KVM acceleration patches for ARM could be backported far enough to make it boot or I can use a newer kernel with broken functionality (as long as 3D works), more to be seen.

I'm a broke uni student but even I alone can afford a cheap machine like that (33 euros, bring it on), so all is good really what I will do:

• Before buying, find a kernel that shows it could maybe work with KVM acceleration and 3D GPU acceleration. After:
  When the above build is ready, I will adapt any step necessary to make sure it uses the GPU and CPU acceleration on real HW (not sure if Mali needs a different backend to Mesa).
• I will get in contact with someone with an OMAP5 dev board to:
  Adapt any PowerVR-specific GLES code.
• Test this.

If it works on the OMAP5 it'll work on the Pyra, so that'd be the moment where we can all drop our dependency on Android phones (which I still don't have, I'm on an N900 still )

So - my dream of having:

Pyra running Debian acting as the host OS

Android as a VM client running on the Debian host for work stuff.

Android as a VM client running on the Debian host for personal stuff.

Android as a VM client running on the Debian host for games/suspect stuff.

That might be possible?

COOL.

Not only might it be possible but there's no technical reason why it shouldn't be possible, it's early to talk but as of now it seems Google have made this easy by separating the forwarders from the translators and by using Qemu, which is very well documented in terms of cross-platform recompilation AND already supports KVM. It also leaves you with additional options like only encrypting the work Android, etc.

All in all, this could potentially be up and running sooner rather than later.

Sorry again for the massive post, I like explaining things in essays

I will get back when there's some real progress or to answer Qs/criticism.

 

[slaeshjag]

No need to hurry about testing it on a OMAP5 devboard, KVM isn't working on PyraOS yet anyway.

 

[lunixbochs]

We might not need KVM for basic Android use. Someone contacted me who's working on a chroot version of this here:

http://talk.maemo.org/showthread.php?s=9a2a578b08e5fddbc040653d2a4c307c&t=95631

I would also recommend greatly against using an Allwinner SoC for testing this. You either get the buggy hacked up sunxi kernel (which in my experience is prone to crashing), or you get a new kernel with no drivers

 

[pablocrossa]

No need to hurry about testing it on a OMAP5 devboard, KVM isn't working on PyraOS yet anyway.

I know, no rush, I just discovered a few additional specs and design characteristics of this project not long ago and got a little hyped

We might not need KVM for basic Android use. Someone contacted me who's working on a chroot version of this here:

http://talk.maemo.org/showthread.php?s=9a2a578b08e5fddbc040653d2a4c307c&t=95631


I would also recommend greatly against using an Allwinner SoC for testing this. You either get the buggy hacked up sunxi kernel (which in my experience is prone to crashing), or you get a new kernel with no drivers

That's awesome, I messed around with some of that before but never got a reliable chroot working

http://talk.maemo.org/showpost.php?p=1425770&postcount=63


That being said, having been there and done that, I'd rather not have a kernel full of Android patches if at all possible... Also the isolation the VM gives is quite cool IMHO, and you get default Android emulator images booting... I just find it more secure, more controllable (set max CPU and RAM usage etc etc) and easier to maintain


We'll see what happens


EDIT: BTW Lunixbochs, you wrote the GLshim package right? Awesome piece of software (http://talk.maemo.org/showpost.php?p=1368436&postcount=30 ), kudos to you


EDIT2: Oh and about the Allwinner, I know it's a patch fest but I only need KVM and 3D working, the kernel Mali drivers are open so I imagine some things can happen there with enough porting, I will see if a kernel shows potential before buying, if I can't get one to build then I will look at other boards. Do you know of other cheap devboards with hardware ARM virtualisation and GLES? Again broke uni student here

 

[slaeshjag]

RaspberryPi 2 supposidly have hardware virtualization. The GPU is a bit iffy with the broadcock stuff, but I did see a patched kernel floating around that adds KVM support.

 

[pablocrossa]

RaspberryPi 2 supposidly have hardware virtualization. The GPU is a bit iffy with the broadcock stuff, but I did see a patched kernel floating around that adds KVM support.

Cool, will take that into consideration, broadcock sounds better than crapwinner...


A little update


I found a version of Qemu by the Linaro guys that boots an Android 5.1.1 image with a tiny bit of modding (probably because I missed a build option) that I've built in ARM 32bit mode without needing an Android SDK or build env with support for ADB and additional commands, such as screen rotating, through telnet, so it's very complete. Through ADB you can install APKs from the Pyra side and through the Telnet commands additional functionality can be implemented in scripts using echo and netcat (I have one to rotate the screen right now). Now I'm porting the GLemu code to work with that Qemu version and that would leave me with removing the GLES to GL translator, wrapping any calls that need wrapping (if not done by the unpacker) and shipping a binary to someone with an ARM board that uses Mesa for GLES with KVM support on the kernel and HW virtualisation, it SHOULD just boot and be FAST.


After that some changes need to happen to the Qemu version just to make sure it works in a way that makes sense on a Pyra (right screen resolution, emulated controller, forwarded sensors, etc ).


Things are hapenning

 

[Eight Bit]

Nice!

I for one would welcome a decent Android build on the Pyra.

Would it handle phone stuff/be able to access the Pyra's sim card?

 

[pablocrossa]

Nice!

I for one would welcome a decent Android build on the Pyra.

Would it handle phone stuff/be able to access the Pyra's sim card?

The emulator emulates a 3G modem, so you could use that (with some work needed on the code) to get it to receive/send SMS and calls, even for mobile data, from several VMs at once


OR


You could probably patch the code to pass through the modem to one VM

but... Why do that? This is a VM so the Pyra subsystem will be available.

 

[WizardStan]

Why do that?

It's easier to sync my contacts via my google account. Also it's already got a very nice dialer, several very nice dialers in fact, whereas the Pyra will likely have a command line utility to start, possibly a very rudimentary QT application that'll take a few months to reach a similar point of user friendliness.

 

[pablocrossa]

Why do that?

It's easier to sync my contacts via my google account. Also it's already got a very nice dialer, several very nice dialers in fact, whereas the Pyra will likely have a command line utility to start, possibly a very rudimentary QT application that'll take a few months to reach a similar point of user friendliness.

I will look into it but, as of now, it isn't a priority for me, when the GPU and CPU acceleration is working with HW controls and the Play store available then I will look into it, there's still a lot of time left until the Pyra arrives so hopefully it will be ready for primetime however I don't know how much work has to be done.

 

[edgex004]

These updates make me so happy. Thanks again, pablo.

 

[Grench]

Why do that?

It's easier to sync my contacts via my google account. Also it's already got a very nice dialer, several very nice dialers in fact, whereas the Pyra will likely have a command line utility to start, possibly a very rudimentary QT application that'll take a few months to reach a similar point of user friendliness.

I will look into it but, as of now, it isn't a priority for me, when the GPU and CPU acceleration is working with HW controls and the Play store available then I will look into it, there's still a lot of time left until the Pyra arrives so hopefully it will be ready for primetime however I don't know how much work has to be done.

If you can get the network bridging to work so that whatever network Debian can see gets bridged to the Android VMs, that would be good enough for my use.  To me, the Android instances are all about 'connected tablet' mode, not so much phone.

Maybe have one Android VM instance be allowed use of the phone aspects of the SIM and any other Android VMs on the same platform be data only?  I could see going there for the contacts & dialer.

So my list becomes...

• Pyra running Debian acting as the host OS handling bridging and passing through the phone aspect to a single VM.
• Android as a encrypted VM client running on the Debian host for personal stuff, dialer, address book & Google synced phone numbers.
  
• Android as a encrypted VM client running on the Debian host for work stuff.
  
• Android as a VM client running on the Debian host for games/suspect stuff.
  

So - how expensive IS a proper dev board to work on this anyway?  Or does it need to be done on a full-on Pyra (or prototype)?

 

[TrashyMG]

So - how expensive IS a proper dev board to work on this anyway?  Or does it need to be done on a full-on Pyra (or prototype)?

Official Ti OMAP5 Devboard is pretty expensive, luckily I'll have uses for it even after getting the Pyra.

http://www.svtronics.com/EVM/OMAP5432/5432 

 

[pablocrossa]

[...]

So - how expensive IS a proper dev board to work on this anyway?  Or does it need to be done on a full-on Pyra (or prototype)?

As TrashyMG pointed out, an OMAP5 Devboard is a little out of reach... However this can be developed on any system that can run the Pyra OS until the kernel for the Pyra is finalised and, if KVM is working, it should just work on it too, so no need for anything fancy


Another of my little updates, this screenshot doesn't show anything impressive but here it is:

This screenshot shows the Android build booted in software GL mode; what's interesting is the black rectangle on the corner.


That rectangle is a subwindow with the correct GL context created by the host rendering library, loaded dynamically at runtime from the code like the emulator does; I am not at the point where anything is drawn there, but when it is I will update again ASAP