Database Info

[Q] How are apps using dual core in the new android phones?

Hi, the way I see it, android (especially the newer versions) are capable of distributing several processes over the dual cores. Apps however don't utilise both cores.
Another question: what kind of apps would benefit from using both cores? I could imagine that heavy games and home launchers could benefit from using both cores.
Are there tools available for android that enable multithreading apps? And what are the average prices of app development tools?
Im currently working in Java, but how do most people write Android apps?
Edit: Just found some information that confirms my thoughts on how android uses parallel structures, but this still leaves open my other questions:
"Android 2.2 already takes advantage of multicore. Anything that multitasks and multithreads already takes advantage of multicore. But this exploitation is a matter of degrees.
Android 2.3 takes further advantage of the multicore, because unlike Android 2.2, 2.3's file system is multithreaded one, not single threaded. When it comes to file I/O or database searches. 2.3 will be a lot faster.
Android 2.4 or 3.1 as rumored to be, will take even greater advantage of multicores with further "architecting" parts of the OS to use more multithreads."

thanks .....

Android apps on windows phone

Hi guys,
I'm currently using an iPhone as my primary phone and android as a secondary one. I want to shift to windows phone (mango) but there are a few apps on the android not available on winmo which I can't live without. Is there any way to run android apps on the windows mobile the same way(or ANY way) its done on the blackberry play book?
Thanks

I don't think there's any. But there are alternate apps.

Android apps on WP7 would be incredibly difficult, though theoretically it could be done with enough effort.
Most Android apps use Dalvik (a dialect of Java). This is totally incompatible with the Silverlight/C# that WP7 apps use, but there are enough similarities between them that it might be possible to build a tool that either translates the Dalvik instructions to MSIL (the binary that compiling C# produces) at launch, or dynamically interprets it (the latter would be very slow, though).
However, even with purely Dalvik apps, there are other problems. WP7 apps are limited to a very restrictive sandbox, with no access to the vast majority of the filesystem (for example). Android apps, by comparison, have a great deal of access to the device they run on, so even a very simple app may expect to have permissions that wouldn't be available on WP7. Instead, attempts to access restricted parts of the filesystem would have to be "virtually" redirected within the sandbox. This is possible in many cases, but a *lot* of work to code and has all kinds of weird edge cases.
Additionally, Android apps have a very different runtime model from WP7 apps. The biggest change is in how they handle leaving the foreground; WP7 apps are either suspended or dehydrated, while Android apps often just keep running (they can elect to suspend, but aren't required to). WP7 does support background tasks (with strict limitations, at least if you stick to the official APIs), but moving the Android app runtime into those background tasks would be quite difficult.
Finally, there's the issue of hybrid apps (apps that use native code in addition to managed runtimes like Sliverlight or Dalvik). These are much more common on Android than on WP7 (at least, than on WP7 outside this webite). Android runs on a Linux kernel, using POSIX system calls and APIs. WP7 runs on a CE kernel, using win32 system calls and APIs. There's a very loose mapping from one to the other (see the Wine project for running Win32 apps on desktop Linux) but it adds a lot of overhead and would be another layer, at least as tricky as the managed part, to the difficulty of this project.
Short version: nope, sorry.

GoodDayToDie said:
Android apps on WP7 would be incredibly difficult, though theoretically it could be done with enough effort.
Most Android apps use Dalvik (a dialect of Java). This is totally incompatible with the Silverlight/C# that WP7 apps use, but there are enough similarities between them that it might be possible to build a tool that either translates the Dalvik instructions to MSIL (the binary that compiling C# produces) at launch, or dynamically interprets it (the latter would be very slow, though).
However, even with purely Dalvik apps, there are other problems. WP7 apps are limited to a very restrictive sandbox, with no access to the vast majority of the filesystem (for example). Android apps, by comparison, have a great deal of access to the device they run on, so even a very simple app may expect to have permissions that wouldn't be available on WP7. Instead, attempts to access restricted parts of the filesystem would have to be "virtually" redirected within the sandbox. This is possible in many cases, but a *lot* of work to code and has all kinds of weird edge cases.
Additionally, Android apps have a very different runtime model from WP7 apps. The biggest change is in how they handle leaving the foreground; WP7 apps are either suspended or dehydrated, while Android apps often just keep running (they can elect to suspend, but aren't required to). WP7 does support background tasks (with strict limitations, at least if you stick to the official APIs), but moving the Android app runtime into those background tasks would be quite difficult.
Finally, there's the issue of hybrid apps (apps that use native code in addition to managed runtimes like Sliverlight or Dalvik). These are much more common on Android than on WP7 (at least, than on WP7 outside this webite). Android runs on a Linux kernel, using POSIX system calls and APIs. WP7 runs on a CE kernel, using win32 system calls and APIs. There's a very loose mapping from one to the other (see the Wine project for running Win32 apps on desktop Linux) but it adds a lot of overhead and would be another layer, at least as tricky as the managed part, to the difficulty of this project.
Short version: nope, sorry.
Click to expand...
Click to collapse
That was quite disheartening for the OP
But I liked the thorough explanation.

for curiosity, which apps are you looking for?

Thanks a million for the detailed reply. I can give up on this now otherwise would have gone crazy searching. As for the apps I wanted to use Rako which basically controls the lighting in my house and creston media which controls my theatre. These I can't live without.
Additional ones would be anonymous email and sms bomb.( to bug my friends)

as for the lighting you got me..
but for media the xbox (if you have one) companion controls my whole xbox media experience from audio (zune), movies (integrated movie player streaming from my pc)..

What about this - http://wp7mapping.interoperabilitybridges.com/Library?source=Android
Can't this be used?!

buffalosolja42 said:
but for media the xbox (if you have one) companion controls my whole xbox media experience from audio (zune), movies (integrated movie player streaming from my pc)..
Click to expand...
Click to collapse
Crestron controls my theater as a whole i.e lights, projector, blu ray etc. I just need to press 1 button and lights dim, screen comes down, blurry starts playing and so on. For the xbox controller its only for the xbox

buffalosolja42 said:
but for media the xbox (if you have one) companion controls my whole xbox media experience from audio (zune), movies (integrated movie player streaming from my pc)..
Click to expand...
Click to collapse
drupad2drupad said:
What about this - http://wp7mapping.interoperabilitybridges.com/Library?source=Android
Can't this be used?!
Click to expand...
Click to collapse
Okay im a noob and i have noooo idea what that is

drupad2drupad said:
What about this - http://wp7mapping.interoperabilitybridges.com/Library?source=Android
Can't this be used?!
Click to expand...
Click to collapse
That is just for developers who want to port their app.

jessenic said:
That is just for developers who want to port their app.
Click to expand...
Click to collapse
Exactly! So yes, Android app can come to WP, only if developers are hard working to port it.
However, I haven't done more than making ROMs for WM, Themes for Android, but I am currently porting 2 apps from Android to WP. Honestly, all porting is made so dead easy that a little bit of English and Bing at hand, and you are off to a great start! It's slow process but anyone can port if they want to.

Droid Charge Hardware Acceleration

Does the DC support hardware acceleration for browser apps? I'm using Dolphin HD as my primary Reddit browser with the javascript from the reddit FAQ, and when it opens alot of images in the browser everything becomes very sluggish, doing redraws after you stop moving your finger instead of smoothly as you go.
The iPhone does this SO much better, because of hardware GPU acceleration. Does the DC GPU just not cut it, is it not engaged due to software issues (on Tweakstock 1.2), or maybe its just a lack of support altogether?

cmdrfrog said:
Does the DC support hardware acceleration for browser apps? I'm using Dolphin HD as my primary Reddit browser with the javascript from the reddit FAQ, and when it opens alot of images in the browser everything becomes very sluggish, doing redraws after you stop moving your finger instead of smoothly as you go.
The iPhone does this SO much better, because of hardware GPU acceleration. Does the DC GPU just not cut it, is it not engaged due to software issues (on Tweakstock 1.2), or maybe its just a lack of support altogether?
Click to expand...
Click to collapse
Yes it does, latest kernel PBJ does tweak the GPU up a little bit (+25). You can use either smoothness, V6 super charge,Thunderbold scripts or voodoo lag fixed to eliminate browser issue. First try xScope browser see it improves your legginess,.

buhohitr said:
Yes it does, latest kernel PBJ does tweak the GPU up a little bit (+25). You can use either smoothness, V6 super charge,Thunderbold scripts or voodoo lag fixed to eliminate browser issue. First try xScope browser see it improves your legginess,.
Click to expand...
Click to collapse
That's not what he was asking. I believe all recent Android revisions support GPU acceleration. It may just be a lack of RAM.
Sent from my SCH-I510 using xda premium

GPU acceleration is only in the stock browser that comes with the shipped ROM. If you modify it, it kills the acceleration from my experience. ICS has a different type of rendering in the browser to make it better/faster than what is available in GB. However, the fact that you're using Dolphin as the browser would have no effect on the browser included in the stock or custom ROM. If you want to know if Dolphin HD does GPU rendering, you'd have to contact them, or ask someone that knows as it would render independent of the included browser.

cmdrfrog said:
Does the DC support hardware acceleration for browser apps? I'm using Dolphin HD as my primary Reddit browser with the javascript from the reddit FAQ, and when it opens alot of images in the browser everything becomes very sluggish, doing redraws after you stop moving your finger instead of smoothly as you go.
The iPhone does this SO much better, because of hardware GPU acceleration. Does the DC GPU just not cut it, is it not engaged due to software issues (on Tweakstock 1.2), or maybe its just a lack of support altogether?
Click to expand...
Click to collapse
Actually the iPhone's smoothness, and Gingerbread's lack thereof, has more to do with the way Android was designed. Take a look at this video: http://www.youtube.com/watch?feature=player_detailpage&v=eWXxCFmKUlQ#t=40s
Notice how on the Vita, despite the rock-bottom rendering times, the browser runs at 60 fps and is perfectly smooth. The Vita OS prioritizes UI input over all other processes (it's a bit more complicated, but this is a close enough explanation).
Android unfortunately runs UI and apps at the same priority, so when an app is accessing CPU resources the entire system chugs. Also as you install more and more apps, your system will begin to experience increasing lag (although some shell scripts can mitigate the problem). Fixing this is not an easy job. You basically have to redesign the OS from the ground up, breaking compatibility with all previous apps.
This redesign issue is why RIM bought QNX and is now using a completely new operating system on their touch-screen devices, instead of redesigning Blackberry OS. It's also why Microsoft threw away Windows Mobile 6.5 and started from scratch with WP7. Same with Palm and webOS, as well as Nokia and MeeGo (before MSFT infiltrated them).
I was hoping Google would just chuck everything and go for broke with ICS, but they decided to play it safe. I personally would have preferred they do what RIM did with buying and implementing a brand new OS, and then using an emulation layer to enable backwards compatibility with old apps. I don't think running an entire OS in a VM on a device with constrained resources (CPU, GPU, and especially battery) makes a whole lot of sense.
But I guess we'll see how it all pans out in the end.

ambrar12 said:
Actually the iPhone's smoothness, and Gingerbread's lack thereof, has more to do with the way Android was designed. Take a look at this video: http://www.youtube.com/watch?feature=player_detailpage&v=eWXxCFmKUlQ#t=40s
Notice how on the Vita, despite the rock-bottom rendering times, the browser runs at 60 fps and is perfectly smooth. The Vita OS prioritizes UI input over all other processes (it's a bit more complicated, but this is a close enough explanation).
Android unfortunately runs UI and apps at the same priority, so when an app is accessing CPU resources the entire system chugs. Also as you install more and more apps, your system will begin to experience increasing lag (although some shell scripts can mitigate the problem). Fixing this is not an easy job. You basically have to redesign the OS from the ground up, breaking compatibility with all previous apps.
This redesign issue is why RIM bought QNX and is now using a completely new operating system on their touch-screen devices, instead of redesigning Blackberry OS. It's also why Microsoft threw away Windows Mobile 6.5 and started from scratch with WP7. Same with Palm and webOS, as well as Nokia and MeeGo (before MSFT infiltrated them).
I was hoping Google would just chuck everything and go for broke with ICS, but they decided to play it safe. I personally would have preferred they do what RIM did with buying and implementing a brand new OS, and then using an emulation layer to enable backwards compatibility with old apps. I don't think running an entire OS in a VM on a device with constrained resources (CPU, GPU, and especially battery) makes a whole lot of sense.
But I guess we'll see how it all pans out in the end.
Click to expand...
Click to collapse
I don't think it would require anything close to the level of rewriting that you are talking about here. We are running, for all intents and purposes, a Linux system with some custom UI layers. It's really no more special than Fedora Linux for x86 or PPC in that regard. Currently, I have mine running quite smooth...almost, but not quite, iPhone smooth...just by playing the renice game with process priorities (SysTune is great for this). As an end user with little desire to dig into the code myself, there's only so much I can do, but what I have done has virtually turned this into a new phone. If Google would change the way they handle the priority of certain basic apps...phone, systemui, media, launcher, etc...they could get the UI to that point by default.
The question then comes down to "why?" Why don't they do this? I can only imagine that there are consequences beyond what we as end users see. Me doing this to my individual phone is fine. If I cause issues, I have to deal with them and have no place to complain, but if Google did this by default and it caused issues on even 10 percent of phones, that's a much greater problem. This is the framework they have to work within. A complete rewrite would be completely outside the Android philosophy. They simply can't do it. RIM can do it because they are using proprietary systems, but Android is built around Linux. It's built around open source. We couldn't have the roms we have or the development we do without that, and Google wouldn't have the massive install base they do if they had a proprietary OS.
Ultimately, we as the end users just have to have faith that Google engineers who are far smarter and more knowledgeable than us have done what they have done for a reason, and the fact that they've decided to make this a mostly open system gives us the ability to tinker with it in ways that iOS, RIM, and Microsoft users can't. I'll take that over a complete rewrite any day.

They haven't done a rewrite because it would break backwards compatibility with all apps and require starting from scratch (with regards to features and such). Palm did this with webOS, but unfortunately didn't have the money or expertise to popularize their phones.
Also it's not just the UI priority, it's the whole running in the Dalvik VM issue. Have you ever lightly flinged your phone's screen to long-scroll a list, and noticed periodic "hiccups" that interrupt the smooth scrolling? That's Android's garbage collection, a unique feature of Java. Its purpose is to manage apps' memory allocations (there's more to it... but that's a good enough simplification), but an always on garbage collector drains battery. Since the entire OS runs in the VM, this tends to result in battery issues.
Unlike Palm, Google has the resources and human capital needed to redesign their OS. They also have a ton of carrier relationships across the globe. A redesign is merely a matter of willpower and risk aversion (and time). I'm still hoping Google is planning to wow everyone with a redesign they've been secretly working on for years.

*facepalm*
Apparently Google may end up releasing Android 5.0 in Q2 of this year: http://www.digitimes.com/news/a20120215PD209.html
I hope the report's suggestion that Google is appealing for dual-boot tablets isn't true. It would just seem... like why would the average person care about dual-booting? I know I would personally like it, but otherwise I doubt the second OS will see much use.

Dual boot to what?
Sent from my SCH-I510 using xda premium

kvswim said:
Dual boot to what?
Sent from my SCH-I510 using xda premium
Click to expand...
Click to collapse
Chrome OS
Sent from my HTC Vision using XDA App

xT4Z1N4TRx said:
Chrome OS
Sent from my HTC Vision using XDA App
Click to expand...
Click to collapse
Chrome OS?? chrome is a browser!. Dual boot between Android 5.0 and Windows 8 OS without shutting down the phone.

buhohitr said:
Chrome OS?? chrome is a browser!. Dual boot between Android 5.0 and Windows 8 OS without shutting down the phone.
Click to expand...
Click to collapse
Actually, google has been making a x86 OS called Chromium. Google chromebooks. It's basically a minimalistic laptop with chromium designed for cloud computing. It uses chrome as the browser, google docs for office etc.

x86/64 bit emulator for ARM Processor

So I was wondering if its possible for someone to create or start developing an application that can emulator x86/64 code on an arm architecture?

What x86 code, exactly, do you mean? Do you mean running native x86 code directly or do you mean taking Java or .NET code and running it?
Ultimately, pretty much *anything* is possible to emulate. However, emulating it in a way that it can run in a reasonable amount of time is unlikely to happen. There are just so many things that are limited in the RT version of the .NET Framework.

ok, im not exactly best qualified for this but ill try and explain
in short, no, you could potentially make an emulator for a given program, but to make some be all end all x86 emulator to cover everything would be massively inefficient and probably not possible
you primary obstacle is that RT uses managed code, that means MS tells you want you can and cant do, it gives you the frame work if you like and you can build what you want within that frame work but step outside it and do your own thing isn't possible (yet)
once you got over that barrier, next up would be to port every single function and call sent to the CPU to an ARM equivalent, ARM is like a tadpole compared to Blue Whale of X86 so it wont do everything on chip meaning youd need to also convert it in software to something it can do
It would be like trying to blow a golf ball through a garden hose
however, small limited programs that don't rely on many hardware functions and with limited calls outside of its own program would potentially be possible to emulate assuming you can get native code to work anyway

Surface RT - Paperweight
Surface Pro - Glorified Tablet/Notebook
Just go with the Pro, it will make life much easier. The whole emulator debacle isn't even necessary if you just go with the logical choice.
I mean the Tegra 3 is awful as an SoC--I don't know what moron said Quad A9's are better than A15's, not to mention the GPU is junk compared to an SGX.
Overall Micro$oft shot themselves in the foot.

qhdevon43 said:
So I was wondering if its possible for someone to create or start developing an application that can emulator x86/64 code on an arm architecture?
Click to expand...
Click to collapse
Actually Visual Studio 2012 could technically support building desktop applications to run on Surface RT and other RT (ARM) tablets. However, at this time, Microsoft is also allowing Microsoft signed applications. And, I heard that if you disabled that check in the registry, then you get blocked by RT. It is definitely possible that in the future, Microsoft might allow desktop applications to be recompiled for RT.
In the meantime, Remote Desktop is wonder in that I can connect to my Windows 8 laptop and use it to run any application with almost full touchscreen functionality. So, combining a Surface RT and a Windows 8 computer is ideal for me.

wrexus said:
Actually Visual Studio 2012 could technically support building desktop applications to run on Surface RT and other RT (ARM) tablets. However, at this time, Microsoft is also allowing Microsoft signed applications. And, I heard that if you disabled that check in the registry, then you get blocked by RT.
Click to expand...
Click to collapse
Add it stands, you can't even really disable UAC without breaking Metro in full Windows 8 (the UI setting to disable it doesn't really disable it). They have that thing locked down pretty well!

You can enable test-sign mode on RT, this would allow you to run your own ARM desktop apps, signed by your own cert, not with MS one. This is absolutely legal, but it can be closed by MS in some of the new hotfixes (and they'll definitely will, when this mode would be used to run cracked apps).
It is really possible to make a working x86 CPU emulator that would allow you to run x86 windows programs on RT. Just remember my port of "heroes of might and magic" 1 and 2 for Windows Mobile - it was more difficult to make it, as WM had a more limited Win32 API than Windows RT has.
I'll make a nearly universal emulator for RT when I'll buy a device, project is already started and has good results. But I'm waiting for a device that is based on quad-core Snapdragon S4. I would not recommend buying Tegra devices, 4-core Krait beats them in CPU and 3D speed. And high CPU speed would be necessary for smooth x86 emulation.

Quad A9's are better than A15. If you wasnt too busy kissing jobs ass, you would know this. Tegra line is alot better that any apple "cpu"
Ace42 said:
Surface RT - Paperweight
Surface Pro - Glorified Tablet/Notebook
Just go with the Pro, it will make life much easier. The whole emulator debacle isn't even necessary if you just go with the logical choice.
I mean the Tegra 3 is awful as an SoC--I don't know what moron said Quad A9's are better than A15's, not to mention the GPU is junk compared to an SGX.
Overall Micro$oft shot themselves in the foot.
Click to expand...
Click to collapse

@Jaxidian: Disabling UAC disables Mandatory integrity Controls, which is how the sandboxes for both IE and Metro-style apps are implemented. Metro-style apps check, when they are launched, if they are running in such a sandbox, and exit if they aren't.
Disabling UAC is, and always was, a terrible, idiotic thing to do, and I truly don't know why MS made it an available behavior. Just set it to auto-elevate without UI instead, if you really can't stand having proper principle of least privilege in your OS. This is a little more complex (you have to use the Local Security Policy editor, which can be launched by typing "secpol.msc" into Run or by going into the Administrative Tools) but is a much better solution as things which explicitly want to be run with limited permissions (sandboxing) still can be.

@dazza9075: Dosbox is an x86 emulator that is already available on other ARM platforms. It just doesn't support the (many) x86 opcodes that have been added since the 386. It certainly can't do 64-bit. However, it's fine for running old DOS programs, including games. Somebody should port it to the Windows Store if possible, or at least see about making a homebrew build of it that we can run on RT devices. This is totally not my area of expertise or I'd do it myself.
A full x86 emulator, like Microsoft's old Virtual PC for Mac (except running on ARM instead of PPC), is technically possible. It's just hard. It sounds like some people are already working on this, though.

Regarding publishing DosBox, Bochs, Qemu, ScummVM and other emulators to Windows Store - they would be unable to pass the certification. Read the requirements here http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx
3.9 All app logic must originate from, and reside in, your app package
Click to expand...
Click to collapse
For emulators - app logic resides in an emulated program that is typically not present in app package.
By the way, Microsoft Internet Explorer can't pass this check too - as it downloads and executes flash from web. But MS is already known for its double-standards.
The other reason why those apps may be refused:
3.5 Your app must fully support touch input, and fully support keyboard and mouse input
Click to expand...
Click to collapse
Old programs (games at least) may be unusable without keyboard or mouse. My own program was refused for this reason, because it is unusable without hardware keyboard.
It is possible (and really easy) to port Bochs or DosBox for RT as a "desktop" application (making a "metro" port would be a bit more difficult). I can do that myself when I'll get hands on a Krait-based quad-core RT device, if someone would not port them earlier.
Regarding Tegra 3 vs Krait - Krait is not directly based on A9 nor on A15.

mamaich said:
You can enable test-sign mode on RT, this would allow you to run your own ARM desktop apps, signed by your own cert, not with MS one. This is absolutely legal, but it can be closed by MS in some of the new hotfixes (and they'll definitely will, when this mode would be used to run cracked apps).
It is really possible to make a working x86 CPU emulator that would allow you to run x86 windows programs on RT. Just remember my port of "heroes of might and magic" 1 and 2 for Windows Mobile - it was more difficult to make it, as WM had a more limited Win32 API than Windows RT has.
I'll make a nearly universal emulator for RT when I'll buy a device, project is already started and has good results. But I'm waiting for a device that is based on quad-core Snapdragon S4. I would not recommend buying Tegra devices, 4-core Krait beats them in CPU and 3D speed. And high CPU speed would be necessary for smooth x86 emulation.
Click to expand...
Click to collapse
mamaich said:
Regarding publishing DosBox, Bochs, Qemu, ScummVM and other emulators to Windows Store - they would be unable to pass the certification. Read the requirements here http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx
For emulators - app logic resides in an emulated program that is typically not present in app package.
By the way, Microsoft Internet Explorer can't pass this check too - as it downloads and executes flash from web. But MS is already known for its double-standards.
The other reason why those apps may be refused:
Old programs (games at least) may be unusable without keyboard or mouse. My own program was refused for this reason, because it is unusable without hardware keyboard.
It is possible (and really easy) to port Bochs or DosBox for RT as a "desktop" application (making a "metro" port would be a bit more difficult). I can do that myself when I'll get hands on a Krait-based quad-core RT device, if someone would not port them earlier.
Regarding Tegra 3 vs Krait - Krait is not directly based on A9 nor on A15.
Click to expand...
Click to collapse
But its only a matter of time before we figure out a way to sideload metro apps without going through the store.

BlueStacks App player

Hi everyone.
Could anybody compile BlueStacks App Player for Windows RT?
It would be great to use this app on our tablet with Win RT
I use on my laptop (win7) and wish o use on my Surface RT
Official site
Thanx a lot

It would be a great app to have, but seeing that it's not open-source there is about zero chance of it ever getting ported by the community.
Your best bet is to just hope that they (the actual makers of the app) decide to bring it over to RT, which is possible but unlikely.
Search next time; the devs here are up to their ears in requests for closed-source applications and are pretty fed up with it. Sorry.

They've actually already stated that it's coming...

Not explicitly. They hinted at it in a Help forum post, but never confirmed or denied it. And that was months ago.

jtg007 said:
Not explicitly. They hinted at it in a Help forum post, but never confirmed or denied it. And that was months ago.
Click to expand...
Click to collapse
Actually they had listed on their site that they were working on an ARM version.but not sure if they still are. Seems unlikely MS would allow it in the store due to direct competition with the windows store.

guitar1969 said:
Actually they had listed on their site that they were working on an ARM version.but not sure if they still are. Seems unlikely MS would allow it in the store due to direct competition with the windows store.
Click to expand...
Click to collapse
MS doesn't have a whole lot of control of things outside the Store. They could side-load an app pretty easily.

The vast majority of RT devices aren't "jailbroken" for sideloading arbitrary ARM binaries. Also, remember that RT doesn't (currently) support OpenGL, which means any Android apps/games that use advanced graphics won't work unless BlueStacks write and include an openGL-via-DirectX compatibility layer.

GoodDayToDie said:
The vast majority of RT devices aren't "jailbroken" for sideloading arbitrary ARM binaries. Also, remember that RT doesn't (currently) support OpenGL, which means any Android apps/games that use advanced graphics won't work unless BlueStacks write and include an openGL-via-DirectX compatibility layer.
Click to expand...
Click to collapse
I meant side-loading a Metro app, which can be done by just about everybody.

Cant sideload metro apps without a developers certificate

Derp. Yes, of course sideloading is the obvious way to go about it. Getting the dev license is easy, and yeah BS would have to sign their app, but that's not exactly difficult and their cert doesn't have to be signed by anybody else; it just requires that the end user install the cert before the app if it doesn't already chain to a trusted authority. The appx installer script automates all of that, though.
That said, the OpenGL issue is still there. Don't count on 3D games, at a minimum, working.

Don't forget however, that all of this is pretty much irrelevant right now. The Surface lacks the power to run Bluestacks. On my 6-core 2.3 ghz 6 gigs of ram computer with a great graphics unit, Bluestacks is still relatively slow. Just imagine it on the quad-core 1.4 with 2 gigs of ram that the Surface has. Not to mention it's on ARM, which is considerably less powerful than x86 or x64.

C-Lang said:
Don't forget however, that all of this is pretty much irrelevant right now. The Surface lacks the power to run Bluestacks. On my 6-core 2.3 ghz 6 gigs of ram computer with a great graphics unit, Bluestacks is still relatively slow. Just imagine it on the quad-core 1.4 with 2 gigs of ram that the Surface has. Not to mention it's on ARM, which is considerably less powerful than x86 or x64.
Click to expand...
Click to collapse
I dont think bluestacks is a multithreaded application in which case your 6 cores would be irrelevant and it would be purely down to your 2.3ghz clockspeed, which is not high at all. 6gb of RAM would also be irrelevant as no android app requires that much RAM so it simply wont be needed. GPU, not so sure what happens there, most of the apps I try running dont seem to enable my GPU at all so I am not sure if bluestacks is using software or hardware OpenGL, but then I havent tried any 3d games or anything. It runs ok on my 3.5ghz AMD athlon 2 but its not always as perfect as lets say a nexus 7 tablet running android natively.

I'm admittedly not 100% sure on how BlueStacks works (is it a native x86 DalvikVM, or is it emulating a full ARM system?), but it should be, at least in theory, possible to get it to run as naively as it does on Android by just porting the DalvikVM to Windows RT. That should result in speeds at least similar to a lower end Android tablet (Windows is bigger and has more cruft than the linux kernel that's running the DVM). With some sort of reverse WINE scenario it should also be possible to get a degree of binary compatibility for native libraries/addons.

SixSixSevenSeven said:
I dont think bluestacks is a multithreaded application in which case your 6 cores would be irrelevant and it would be purely down to your 2.3ghz clockspeed, which is not high at all. 6gb of RAM would also be irrelevant as no android app requires that much RAM so it simply wont be needed. GPU, not so sure what happens there, most of the apps I try running dont seem to enable my GPU at all so I am not sure if bluestacks is using software or hardware OpenGL, but then I havent tried any 3d games or anything. It runs ok on my 3.5ghz AMD athlon 2 but its not always as perfect as lets say a nexus 7 tablet running android natively.
Click to expand...
Click to collapse
Sort of, yes. But still, that means the Surface would be way less powerful. Also, my RAM is EATEN by Bluestacks because it's not apps that are the problem to run, it's Android. You're basically loading an entire virtual machine onto your RAM to run, in a program shell, then running Android apps on top of that. So the power of the device does matter... however:
netham45 said:
I'm admittedly not 100% sure on how BlueStacks works (is it a native x86 DalvikVM, or is it emulating a full ARM system?), but it should be, at least in theory, possible to get it to run as naively as it does on Android by just porting the DalvikVM to Windows RT. That should result in speeds at least similar to a lower end Android tablet (Windows is bigger and has more cruft than the linux kernel that's running the DVM). With some sort of reverse WINE scenario it should also be possible to get a degree of binary compatibility for native libraries/addons.
Click to expand...
Click to collapse
Bluestacks would have to run a full emulation of ARM in order to run all apps, right? Because when you install native x86 Android, it runs very few apps from the store, because they aren't compiled for ARM.
Netham45 could be right though that we could kind of make Android run natively, though I'm highly dubious about it happening through Bluestacks. Bluestacks most likely won't make an ARM port (especially cause I doubt Microsoft would allow it in the store) and if we did have access to source code, it's still built around running on Intel processors, and would probably have to go through all sorts of unnatural emulation... So making a totally separate Android program from scratch (which would require inordinate amounts of work) would probably be the best bet.

No. I think bluestacks is actually "just" a port of the dalvik VM to run on windows.
Android apps are not compiled for a specific CPU type. They are compiled for the dalvik virtual machine which is in a way similar to the java virtual machine, in fact a dalvik applications source code is java source code hense why many people say android apps are java, in reality the dalvik VM is very different from the java VM and the 2 are not compatible.
The vast majority of apps do actually work on x86 just fine.
The main problem is that google restricts apps based on your device and often it doesn't recognise x86 devices so doesn't show results, the default app manifest files don't actually restrict platform but many devs set them to arm for some reason. With various tools to spoof what device you appear as you can still gain access to thses other apps.
The problem apps are those that use the NDK (a small minority). NDK apps do have native code, but not just for ARM. The NDK default settings are to generate binaries for ARMv7, but it can be set to x86, ARMv6, MIPS or to compile multiple binaries for a mixture of the above (causes its own issue as it includes the binaries for all platforms in one APK which loads the relevant binary at runtime, good for compatibility as one APK covers all devices but makes the final APK massive). x86 devices of course cannot run ARM compiled apps which does include a few big name apps.
I don't know if bluestacks has left it as pure dalvik VM on x86 or if it does include an ARM emulator for the NDK but it certainly isn't just running an ARM emulator and tyen android atop of it.
I don't experience the ram eating effects you mention either.

SixSixSevenSeven said:
No. I think bluestacks is actually "just" a port of the dalvik VM to run on windows.
Click to expand...
Click to collapse
That's exactly what my understanding was as well, although what I'm about to say somewhat contradicts that.
Interestingly, http://www.bluestacks.com/technology.html says that BlueStacks is "fully configurable" and that it "supports" Windows on ARM as well as x86 Chrome, even though neither of those are actually available today. So, not sure if that page is before or ahead of its time.
"BlueStacks employs a lightweight, optimized, soft hypervisor with deep enhancements to support "embedded virtualization". End consumers can enjoy the full Android environment through BlueStacks, or just install Android app icons directly on the Windows desktop."
What the page basically says is that the core virtualization that BS uses is very easily configurable to different combinations or permutations of OSs; that the technology can just as easily run Windows on Android or Android on Chrome as it can Android on Windows, which is the only current release. It also implies that BS can do BOTH a mere dalvik vm (just install apps to the Desktop) as well as a complete system emulation (full Android experience).
There may be hope for RT yet.

As far as I remember, Bluestacks is using QEMU as there base platform. So it's probably still running ARM code in emulator.
I am looking at if we can port the Dalvik VM over to Windows RT. Anybody want to join the explorations?
So far I can see the Dalvik VM has lots of generated ARM assembly code and have huge dependencies on linux.
Porting would need quite a bit of effort.
Developers from Windroy has done it for the Windows X86 platform. If they can do it for Windows RT, it'll be much easier.