[Q] TF101 - compatiility problems in Google Play Store - Eee Pad Transformer Q&A, Help & Troubleshooting

Hi everybody,
I've decided to upgrade my TF101 to KatKiss 4.4 mainly due to the fact that I intend to use Microsoft PowerPoint and Microsoft Word which are available for install from Google Play Store. Important thing is that they require Android in KitKat version (4.4) at least. My current installation seems to fulfill this requirement, however, in Google Play when I try to download & install these apps I obtain the message that my device is not compatible with this version.
Did anyone has similar problem?

Well, no one answered. Maybe I'll ask another way - did anyone succeeded in installing Microsoft Power Point from Google Play on TF101 with KatKiss 4.4?
Perhaps only I have such problem?

prezes22 said:
Well, no one answered. Maybe I'll ask another way - did anyone succeeded in installing Microsoft Power Point from Google Play on TF101 with KatKiss 4.4?
Perhaps only I have such problem?
Click to expand...
Click to collapse
The MS-office apps require NEON compatible devices. They won't work with our Tegra2.

doppelhelix said:
The MS-office apps require NEON compatible devices. They won't work with our Tegra2.
Click to expand...
Click to collapse
On Microsoft website I've found the following information regarding hardware requirements:
Office for Androidâ„¢ tablet can be installed on tablets running Android KitKat 4.4 with a minimum screen size of 7 inches and an ARM-based processor. Office Mobile for Android phones can be installed on phones running OS 4.0 or higher.
NEON extension is not mentioned. Tegra2 is an ARM based processor, isn't it sufficient for these apps?

prezes22 said:
On Microsoft website I've found the following information regarding hardware requirements:
Office for Androidâ„¢ tablet can be installed on tablets running Android KitKat 4.4 with a minimum screen size of 7 inches and an ARM-based processor. Office Mobile for Android phones can be installed on phones running OS 4.0 or higher.
NEON extension is not mentioned. Tegra2 is an ARM based processor, isn't it sufficient for these apps?
Click to expand...
Click to collapse
Thats because non-neon devices are practically non-existent. Only a very very small amount of devices are out there that requires apps to be compiled explicitly with non-neon flags. That the tegra2 has no neon support is one of its major drawbacks.

doppelhelix said:
Thats because non-neon devices are practically non-existent. Only a very very small amount of devices are out there that requires apps to be compiled explicitly with non-neon flags. That the tegra2 has no neon support is one of its major drawbacks.
Click to expand...
Click to collapse
So no hope that these apps will work on TF101?

Related

Why so few Android apps compiled for MIPS?

This is something that is driving me crazy, shouldt be MIPS Android SDK and NDK be compatible with any source maded for the ARM version?
First thing i noticed with this Ainol Novo 7 Basic was that, the small amount of compatible apps, none of the better apps are compatible.
No: Netflix, Skype, Android Terminal Emulator, MX video Player, Chainfire3D, any mame32/nes emu, a working barcode reader, connectbot, adosbox/qemu, opera or any other browser. and the list goes on.
I wonder why, i trought devs will want the larger amount of users as posible.
For the record, i just got Android Terminal Emulator working in my Novo 7 Basic, i had to:
1) Download Term source code
2) Download MIPS Android SDK, NDK, Apache ANT, Eclipse with ADL, cgywin (to compile NDK libs)
3) Import Term project to eclipse
4) change the target build to android-12
5) change Aplication.mk to "APP_ABI := mips mips-r2"
6) build ndk-libs for the app
7) build the project with eclipse
And i know nothing about programing for android, just c/c++
Best guess that anyone will probably give you is that the majority of devices out there running Android are ARM based, but as that changes, the number and quality of available apps should improve.
There is a HUGE obstacle to overcome however. Not many people are going to buy a device today based on what might run on it months from now, especially when there are devices out there that will run it now, and many of those that do purchase a MIPS based device consider it a mistake and end up returning it.
It is not possible to offer two different version on the market and i don't think it is possible to restrict the apps to a specific architecture.
Are the number of MIPS devices really rising? The android market doesn't really seem to be ready for that. It would mean even more app versions devs would have to consider.
Which apps work and which don't?
Maybe those using native code, compiled with NDK don't work, as those routines are compiled specificly for ARM.
Don't take my word for it though, just some thoughts.
its not possible to get 2 different versions on the market.
Rumor has it that the problem is frequently a development oversight and that it's related to omitting some important MIPS related files from the package build.
I imagine that it can also be related to poor programming practices and also programming for optimized code.
~~ Sent from my Velocity Micro Cruz PT701/T105 via Tapatalk ~~
As far as I know, Market supports device specific apk's nowadays, which would make it possible to have an mips apk...
http://developer.android.com/guide/market/publishing/multiple-apks.html
Altough the proccess is not trivial, it is not that difficult either, just minor changes to the manifest and filter the apk for Native Platform...
Also, it would be possible to compile it for all devices that the current NDK supports, by using the latest revision of NDK (as of November 2011):
http://developer.android.com/sdk/ndk/index.html#overview
You just need to add:
APP_ABI := all
Click to expand...
Click to collapse
to the makefile and it should now be compatible with all processor architectures that NDK supports....
So, now there are means to easily support different processor architectures, but, don't expect quick adoption of it, as, unfortunately, this depends entirely upon developer will to change some of its project settings and/or publishing way (it is entirely possible, now, to have a single apk for all platforms)...
Unfortunately, right now, and I would dare to say, in the next 6 - 8 Months, I would not expect this to change much... Altough the official NDK has support for multiple devices, it still doesn't incorporate the MIPS abi, which is not official, and thus, it is not possible to declare that an APK for a native MIPS device as well...
Hopefully MIPS devices will grab a nice piece of the Android devices and then "force" Google to officially support those devices. I believe that it is possible to grab the latest unoficial NDK and use it with APP_ABI all and publish it to the Market, but, as of today, is mostly something recent and that few (if any) developers support (remember, this possibility came with November's NDK, I'm not even sure if MIPs NDK is already up to date with Google's November NDK), so, I would dare to say, MIPS devices are not in a good position right now (even x86 devices, which have official support, are not...).
I have a MIPS based tablet named "MIDI Japan MD-785IP" that is quite nice but is making me sad with the lack of some softwares and in special, lack of ROMs to it. Apparently I am the only person in the internet that have one
shivansps said:
This is something that is driving me crazy, shouldt be MIPS Android SDK and NDK be compatible with any source maded for the ARM version?
...
For the record, i just got Android Terminal Emulator working in my Novo 7 Basic, i had to:
...
Click to expand...
Click to collapse
Hello,
Have you shared that MIPS compatible Android Terminal Emulator?
Thank you
Sure... and here is connectbot too.
Ive attemped to recompile adosbox too but the source code and makefiles are just a big mess and no documentation provided.
And that is another problem, poor documentation in open source projects.
BTW, Market has to have some way to know if a app is for arm or mips, since market on basic only shows up compatible apps.
Also, its no enoght to just incluide the "mips" folder along with "armabi" with all mips compiled .so files inside the libs folder? because is that all what it takes, unless the app is using binaries.
And im agree that google has most of the fault for not incluiding mips supprt in his NDK, the mips one can compile for both.
I wonder what will happen when intel medfield will came out...
I am in an even worse position - I bought 2 NOVO7Paladins - one for the g/f. I had to get one for myself, because I know I will be 1st line support
So, I have a MIPS cpu (with reduced software availability) and also ICS which further reduces app compatibility.
Apps which I consider essential (Samba server, VNC Server, Angry Birds Seasons....) are not available, so l'm currently installing eclipse, JDK, SDK, NDK on a linux box to try to rebuild stuff - it has been many years since I last had to get my hands dirty with code.
I know I have a steep learning curve ahead, but I'm sure it will be many months before there is a significant increase in app availability. I understand though, that if developers have written native code for ARM, they won't be in a hurry to port that to a minority cpu. It is way easier for new apps to be built with different architectures in mind.
Thanks Shivansps, I had been looking for a terminal - I had given up and was trying to get telnet working - a last restort. It was either that or carry a laptop around with me to use ADB
Now, all I need is to get the MIPS ABI to appear in Eclipse AVD setup... (oh, and learn how to code for android )
i dont use Eclipse or SDK myselft any longer, what i do is just recompile shared libs with mips NDK and include the new "mips" folder intro the libs folder of the original .apk file, then re-sign the apk with one click signer.
MapsWithMe for MIPS and x86
maersi said:
I am in an even worse position - I bought 2 NOVO7Paladins - one for the g/f. I had to get one for myself, because I know I will be 1st line support
Click to expand...
Click to collapse
Hi! Do you still have MIPS android device?
Would you please test MapsWithMe on it? It's offline world maps based on OpenStreetMap.
We've built apk for mips and x86 architectures but doesn't have any devices to check if it works.
Apk is available here: dl.dropbox.com/u/24013616/MapsWithMe-203-mips-x86-120502.apk
Cheers,
Alex Zolotarev
MapsWithMe Team
AlexanderZolotarev said:
Hi! Do you still have MIPS android device?
Would you please test MapsWithMe on it? It's offline world maps based on OpenStreetMap.
We've built apk for mips and x86 architectures but doesn't have any devices to check if it works.
Apk is available here: dl.dropbox.com/u/24013616/MapsWithMe-203-mips-x86-120502.apk
Cheers,
Alex Zolotarev
MapsWithMe Team
Click to expand...
Click to collapse
Yes, I still have a mips tablet, but it hasn't gps. Do you want me to check it?
Enviado desde mi ThL W8 usando Tapatalk 2

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.

[Q] Use unofficial apps Surface 2 RT + playstore ?

Hi,
I want to buy a Microsoft Surface 2 with Windows 8.1 RT.
I want to know is a jailbreak is possible for this tablet, to allow me to launch unofficial apps like "the no RT windows".
I also want to know if it's possible to install Android Playstore on it, and if it's possible to watch football stream like on this site on it : http://xn--frstrowsports-39b.eu/
Thanks
OK, first of all (and should be obvious): There's no jailbreak (which is a software mod) to make an ARM processor run x86 code. That's like asking if you anybody has a way to turn an iPad into a MacBook Pro.
Second: There's no (publicly released) jailbreak for RT 8.1 at this time, but if you want to you can downgrade to 8.0 (may take a little work to get it going but is said to be possible) and then use the 8.0 jailbreak. This will let you run code on the Desktop, but the programs still need to either be .NET based or need to be recompiled from x86 (normal Windows CPU architecture) to ARM (mobile device CPU architecture). See the link in my signature.
No, you can't run Android apps on it. Same way you can't run iOS apps on Android or Android apps on iOS, or Mac apps on Windows.
There are lots of apps on the Windows store for streaming sports videos; I don't know about one for that in particular.
Okay, thanks for your help.
Because i have to choose between a Galaxy Note 10,1" and the Surface 2.
But i don't know if the surface is a good choice, because of the market. The market is really poor i think...
So, on this tablet, we are unable to use Google Chrome for exemple ?
Google has not released a version for RT, so you are correct that it won't work.
On the other hand, the Surface has full IE8.1, not just a crippled mobile UI, meaning it can do things like tracking protect/ad-blocking. It also supports (comes with) full Flashplayer, which hasn't been available on Android for years. Don't know if you find that useful.

[ROM] Android Gingerbread on Zedboard not reacting to Touch/Mouse input

Hi,
I know that Android Gingerbread is quite old so probably most people would not bother to port it any more, but I need it for a university project where the hardware resources are very limited.
After a lot of work, I managed to build Android Gingerbread for the Digilent Zedboard, but it is not reacting to any touches on my USB touchscreen or to movements/clicks with a USB mouse.
getevent provides the expected events and I tracked them in InputReader.cpp and they seem to be dispached fine, but the UI does not react to the input. I can see that the events are enqueued, but cannot find where Android actually picks up those events and works through that queue. Does anybody have an idea?
I followed a tutorial on elinux.org (I am not allowed to post links yet. It's elinux.org [slash] Zedboard_Android)
with small modifications (enabled USB touchscreens in the kernel config, switched to a different android repo since the one in the article is offline)
Any help is much appreciated.
Thank you!
Android Gingerbread is no longer supported, and cannot use Google Play Services.
Why are you trying to run Gingerbread?
Please read THIS BEFORE responding.
Thanks for the answer!
x13 said:
Android Gingerbread is no longer supported, and cannot use Google Play Services.
Click to expand...
Click to collapse
I do not need Google Play Services.
x13 said:
Why are you trying to run Gingerbread?
Click to expand...
Click to collapse
We are trying to show dynamic partial reconfiguration with Android. For that purpose, we selected the Xilinx Zynq processing system. It consists of a dual-core ARM processor and an FPGA. The point is to reconfigure parts of the FPGA from Android during runtime.
Unfortunately, we were unable to find hardware designs for the upper-level Zynq chips and do not have enough resources to build one ourselves. Therefore we are stuck with the smaller chips and went for a ZedBoard.
At a point in history (I am not sure when) there was even official android support for the ZedBoard by iveia. They used android gingerbread, thats the first reason why we chose to use it.
The second reason is that the ZedBoard has very little resources (slow processor, little RAM, no GPU), which disallow more current Android versions to run. Some people got more recent version booting (google noritsuna android zedboard), but they reported it being slow since there is no gpu and low ram (they used linux swap since the built in ram is not enough for android - but linux swap from an SD card is terribly slow). Also, we were unable to replicate their build. All build processes go through but it does not boot. No debug output is available - not even kernel messages over UART. I suspect the u-boot setup is wrong but am no expert and cannot fix it.
Gingerbread is working fine (except for the touch issue), so we decided to stick with it.

Categories

Resources