ARM-Emulator from Intel
Phil Osoph
yesterday I read something about the Android 4.0 Version from Intel
shown at the CES2012... For running native apps, Intel integrated a
new ARM-Emulator... Does it work?^^
And what does it mean for us if this works? Could this be an solution
for the apps which wont work now, like games???
Greetz,
Philipp
Amogh Harish
As far as I know, emulating ARM's is tricky, and I doubt it would work. For which device was this stated? In the case that it did work, the apps that depend upon the ARM structure would work, although I don't see that many apps which can do that.
> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-x86...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-x86?hl=en.
>
Yi Sun
Kirn Gill
the NDK. Since we're running on x86, these apps won't work - they'll
call the functions to load the library, Dalvik will look in the .apk
for an x86 version, and failing to find one, will simply return a
"library not found" error, the app FCs, and the ARM build of the
library is never even considered, after all, it won't run on an x86
CPU anyways.
Prominent examples of apps using ARM native libraries:
Opera Mobile (and Opera Mini)
Angry Birds (most games, for that matter)
Go find .apk files floating around on the 'net and try to install and
use them on Android-x86. You'll find they simply don't work at all.
On Feb 6, 7:06 pm, Amogh Harish <amoghharish...@gmail.com> wrote:
> As far as I know, emulating ARM's is tricky, and I doubt it would work. For
> which device was this stated? In the case that it did work, the apps that
> depend upon the ARM structure would work, although I don't see that many
> apps which can do that.
Kirn Gill
Android-x86 is a fully open source project, and including closed
source bits would be against the whole point of the project.
On Feb 6, 6:57 pm, Phil Osoph <philipp.b.muel...@googlemail.com>
wrote:
Amogh Harish
Would this mean that the Application Compatibility Layer released for MeeGo called Alien Dalvik return a force close error as well when running games or apps that require native libraries?
Kirn Gill
also possible that the games will run on MeeGo devices powered by
compatible ARM CPUs. Of course, that would require either including
Bionic (the Android C runtime library) or mapping calls to Bionic
instead to the GNU C Library on those devices.
Most MeeGo devices are ARM, so that's not a big issue.
On Feb 7, 2:49 am, Amogh Harish <amoghharish...@gmail.com> wrote:
> Would this mean that the Application Compatibility Layer released for MeeGo
> called Alien Dalvik return a force close error as well when running games
> or apps that require native libraries?
T K
maybe i am missing the point here, but whats about including the
virtual ARM SoC called Goldfish which comes with the Android SDK? I
dont know about wether the SDK could be OpenSource or not...
However I am not capable of doing this but i read about the emulation
here: http://elinux.org/Android_on_OMAP
regards,
T K
Amogh Harish
What happens in the SDK is really simple. An SDK's main function is to emulate a certain OS a device runs on. They have libraries that are compatible with the host OS you are running it on. Goldfish is basically what it states it is. As mentioned above, Android requires certain libraries that are not compatible with Intel or AMD processors. They mainly operate on ARM based processors like ARM 7, Snapdragon and so on.
For developers to test their apps without fear of damage to their real devices, it is tried on the SDK first. For this it has to emulate the binaries associated with ARM processors. Since the host has a good RAM and processing unit, it is able to pull this off.
Amogh Harish
And also, the Android SDK is open-source!!
On Feb 7, 2012 9:59 PM, "T K" <dopp...@yahoo.de> wrote:
>
Joshua Parnell
From: Amogh Harish
Sent: Tue, Feb 7, 2012 12:6 PM
To: andro...@googlegroups.com
Subject: Re: ARM-Emulator from Intel
What happens in the SDK is really simple. An SDK's main function is to emulate a certain OS a device runs on. They have libraries that are compatible with the host OS you are running it on. Goldfish is basically what it states it is. As mentioned above, Android requires certain libraries that are not compatible with Intel or AMD processors. They mainly operate on ARM based processors like ARM 7, Snapdragon and so on.
For developers to test their apps without fear of damage to their real devices, it is tried on the SDK first. For this it has to emulate the binaries associated with ARM processors. Since the host has a good RAM and processing unit, it is able to pull this off.
Amogh Harish
We're running the x86 as a stand alone OS. The ARM emulator is based on the host OS. It is impossible to implement it on x86.
Kendiv X
Andy in Indy
Phil Osoph
Chih-Wei Huang
If you build AOSP, you can get it.
IMO, it doesn't make any sense.
It's just an emulator based on qemu.
And it's as slow as the SDK arm emulator.
Besides, it's totally not the "arm amulator" you expected.
2012/2/9 Phil Osoph <philipp....@googlemail.com>:
> Look at that...
> http://pastebin.com/FLLqD0ZQ
> intel released its android x86 emulator...
--
Chih-Wei
Android-x86 project
http://www.android-x86.org
Ron M
I agree that adding an emulator feature just for the sake of
supporting the ARM native stuff doesn't make much sense on an
effort/usefullness scale - although a project I am working on could
benefit dramatically from that, and I would be glad to participate in
such a work - for personal reasons.
I believe the more X86 based devices are out there - the more ABI=all
applications we will see, despite increasing the APK sizes. I don't
think anyone (well at least not 90% of them) really cares about the
APK sizes.
As for the emulator-x86 performance: from my experience, when used
with kvm, it's outperforms the arm emulator in orders of magnitude.
Nothing to compare.
Ron
Chih-Wei Huang
> Chih-Wei,
> I agree that adding an emulator feature just for the sake of
> supporting the ARM native stuff doesn't make much sense on an
> effort/usefullness scale - although a project I am working on could
> benefit dramatically from that, and I would be glad to participate in
> such a work - for personal reasons.
No, I didn't mean supporting arm native doesn't make sense.
(It really makes sense IMO, but not that easy)
I meant emulator-x86 doesn't make sense.
It's an x86 emulator (actually qemu-x86), not an arm emulator.
It's totally not what you want.
Since we are able to run android native on an x86 machine
(or virtual machine like vbox or vmware),
why do we need an x86 emulator to run android?
So I said Intel's approach doesn't make much sense.
Phil Osoph
games???
Joshua Parnell
be more time and resource consuming than its worth. Besides, in order to get
x86 to run ARM apps defeats the purpose of enabling android to be x86.
The sensible approach would be to get this project famous and get developers
to develop their apps to be compliant with x86 architecture. This will be a
difficult and slow moving process, but then again, so was getting Android
apps available for tablets. After about a year, you don't see many apps that
don't have a tablet ready version.
-----Original Message-----
From: andro...@googlegroups.com [mailto:andro...@googlegroups.com] On
Behalf Of Phil Osoph
Sent: Friday, February 10, 2012 9:15 AM
To: Android-x86
Subject: Re: ARM-Emulator from Intel
--