More specifically, I'm wanting to run OpenCL / Renderscript code in an Android Emulator that actually runs on my computer's GPU instead of CPU. Unluckily I'm using an AMD CPU and GPU.
I know that AMD has OpenGL ES support (and everything supports OpenCL pretty much) via SDKs but that's as far as I've gotten on that front - the only OpenCL / Renderscript information I've found regarding emulators is that they either don't work at all or, if I had an Intel CPU, I could install OpenCL in the emulator but it would only use the CPU (and frankly I wouldn't be surprised if behind the scenes my emulator(s) aren't already doing this - OpenCV runs without incident but OpenCL-Z says there's no OpenCL support).
Is there some way to send the commands from the emulator to my OS and have it automatically run? The only ways I've come up with involve saving and loading a text file which isn't likely to be faster (or good for my hard drive) given I'm running 2 Emulator Instances.
I found some mention of RenderScript being supported in the official emulator but said emulator isn't meant for my use-case and I strongly doubt that it's going to use my GPU.
I'm using Memu at the moment because Bluestacks 3 uses more resources when running 2 instances and the 2nd instance doesn't work very well with adb commands / root for some reason - it thinks it's working but it doesn't do anything. If there's a faster emulator when it comes to running 2 instances I'm sure it would help but oddly enough comparing them is difficult and time consuming (especially when every one of them is like "No, I'M the fastest - look at MY bar graphs!" lol) and ultimately I believe my problem to be with OpenCV not getting GPU acceleration (because it runs much faster on my phone) and not the emulator's base speed.
I have AMD's virtualization features enabled (confirmed with Leomoon or w/e) and they're enabled in the manager for Memu. Perhaps this is already working behind the scenes, then? Either way, emulation costs increase by 10% per instance once the OpenCV stuff comes into play (taking it from 60 to 80%+)
Use a language (like Python) and send commands via ADB. Python can hook into OpenCL and OpenCV; ADB can be used to get the Framebuffer for screenshots or Python can just capture the emulator's window render.
Alternatively, a connection can be made using SocketIO (Flask Socket IO and Javascript's client socket IO in my case) and they can communicate that way. Confirmed via the browser on the emulator and real device. Every emulator has ports to communicate to your native OS. I ultimately chose not to go this route as it's a little convoluted (2 servers, different languages, no better than ADB over LAN) but it's an option. Java (iirc) also runs SocketIO just fine and would likely be a decent option for many devs who are familiar with the language and wish to run some stuff natively on Android Devices.
Feeling physically ill atm and typing on a phone so my apologies for the present lack of examples and assistance. Hopefully I can catch the time to address this but, frankly, there are few use cases for this outside of the one I'm presently targeting and it's quite niche to begin with.
Is Way To Run Machine Code Instead Android OS In Android Devices ?
I Want Remove Android Os And Work With Cpu And Other Devices Directly .
What Compiler I Can Use ?
MASM is an x86 assembler, so it would not be suitable for most Android devices as the vast majority use ARM-based processors.
That said, Android phones are computers just like any other and can be programmed in assembly. The first thing you'll need to do is select a device running a well documented CPU and chipset.
Since you'll be removing Android and plan on programming in assembly you'll need to write your own routines for nearly everything. An understanding of the CPU, power management and some form of I/O (you can avoid having to write complex display code if you plan to interface with the phone through serial communication, for example).
Unfortunately, much of the information required for successfully writing your own OS for an Android device is unavailable so you'll need some hardware analysis tools to assist in reverse engineering some of this information. A logic analyzer may be useful in sniffing some of the protocols used between chips, although much of modern phones is done on a single SoC, so you'll need to experiment heavily and compile information from a wide variety of online sources.
Aside from that, it's smooth sailing. Programming an OS in assembly for Android is pretty much the same as programming an OS in assembly for any other computer and you'll find it to be rather familiar territory.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Just Curious. Did Apple do an awesome job with their iPhone simulator?
When Compared,The android Emulator running on i7 and iPhone simulator on i3. The iPhone simulator is faster than the real iPhone.
Did I fail to set things up right?
It's a matter of architectural decisions:
iOS simulator runs native code, directly on your CPU - the project has to be recompiled for x86 architecture to be used with simulator. The simulator itself simply emulates all the iOS APIs.
Android emulator, on the other hand, uses QEMU to run ARM (or x86, but ARM is more popular) CPU virtual machine, with all the software stack on top of it - Linux kernel, Android system image, etc. Think of it as an emulated hardware.
It's a sort of trade off - the way iOS does it is much faster, but it is harder to make it 100% compatible with the target system. For Apple it was perhaps a bit simpler, as iOS and Mac OS have many things in common.
For Android it makes a lot of sense to emulate the whole stack - it is easier to build cross-platform SDK, easier to test some system level components with it, etc. It's simply a different ecosystem, with different goals. Don't forget, that Android emulator can be used e.g. to test native ARM libraries compiled with Android NDK.
Today the Android emulator performance is more or less acceptable, but it was just a disaster in the early Android days. That said, personally I think that fast, API-level native simulator for Android would be a great addition to the SDK, making it possible to test less demanding projects much faster.
Interesting reading: http://logic-explained.blogspot.com/2011/09/why-is-there-no-x86-native-emulator-for.html
iphone ,iphone simulator,apple laptop ,xcode are apple products
but android
windows-Microsoft
android -Google
eclipse -eclipse vendor
these tools are different vendors that why android simulator slow.
i am just kidding :)
Apple Simulator is created using system configuration means it will take the System's ram, memory,cache automatically you don't have to configure it, so an Iphone Simulator is not act as real device but in case of Android one has to provide all the configuration details before creating the emulator,Android emulator to a great extent will act as real device but can be much slower than an Iphone Simulator.
Yes that's true, The emulator (FYI) is slower then simulator.
Does apple did an awesome job with the iPhone simulator?
No other developer can answer this because iOS is not open-source.
Did I fail to set things up right?
No, you are right at everything.
First of all Android does not have a Simulator it has an Emulator.
Secondly I believe the speed of the Emulator depends on your machine config. Better the config the better it will run provided you have created the AVD properly and given it ample memory.
That's simple:
Android Emulates real device, so real architeture and really close behaivour and layout.
In other hands apple simulator is not an emulator, so you can't expect real behaviour, but it has a close layout, which mainly solves for IOS, as you needs only 1 device to test the app behaviour.
Android SDK has an emulator, Whereas ios SDK has simulator.
A simulator behaves similar to something else, but is implemented in an entirely different way. It provides the basic behavior of a system but may not necessarily abide by all of the rules of the system being simulated. It is there to give you an idea about how something works. It uses Desktop resources like processor, ram etc.,
An emulator is a system that behaves exactly like something else, and abides by all of the rules of the system being emulated. It is effectively a complete replication of another system, right down to being binary compatible with the emulated system's inputs and outputs, but operating in a different environment to the environment of the original emulated system.
Thus simulator will be definitely fast compared to emulator.
The Android simulator is actually an emulator, designed to mimic a mobile device running Android, meaning it emulates the hardware running Android OS, to make it as close to 100% identical as possible. The JVM converts Java bytecode into ARM instructions that are decoded by the emulator.
The iOS simulator works at a higher level, simulating the operating system and its libraries, translating OS calls into OS X implementations and simulating events in the other direction like device rotation or low memory conditions. When you run an app on the iOS simulator, the app is compiled into x86 that runs natively on your Mac. Unlike the Android emulator, your iOS app won't run out of memory in the simulator because it's not constrained to any particular iOS device's memory limitations.
I've developed an Android application and I'm running it on a android virtual machine in order to get a faster execution of my application, but how can I compare the virtual emulator performances to those of a real device?
Thanks
This answer may not be what your looking for. I dont think you can compare performance between an emulator and any real device. Firstly because your software isnt running on the target hardware. The emulator may be doing all sorts of additional things to make it look like that hardware. there will be layers of software running your software generally making your programme run slow.
The best thing you could do is do some performance profiling https://stackoverflow.com/questions/2713940/eclipse-java-profiler which would show you where bottle necks are and give you some idea of performance.
There's no real substitute for running on the target hardware. emulation will show you your software is functionally working but it may hide timing bugs it you have time critical code.
the virtualbox is just an emulater. it wont carry out the application's full preformance, as it has to go through multiple layers of software. for testing out apps, a real android device is necassesary.
I am working on a compute intensive app for Android. I do not have any device yet to test performance. However, the performance on emulator is a bit slower than expected.
I see an old question about some estimation of emulator vs device. What are your experiences while developing apps with recent SDK Froyo/2.2. Is performance observed on emulator is slower than actual device.
Please share your experience and the specs of your dev machine and mobile devices, both.
Note: To get virtual device's CPU speed one can run cat /proc/cpuinfo from adb shell. How is this comparable to actual device's CPU frequency?
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 240.02
From a CPU standpoint, the emulator tends to be slower than actual hardware, presumably due to the overhead of converting ARM bytecodes to x86 ones on the fly.
From a graphics standpoint, the emulator tends to be dramatically slower than actual hardware, because the emulator lacks hardware graphics acceleration (regardless of the quality of the host computer's video card).
From a disk I/O standpoint, the emulator tends to be faster than actual hardware, particularly on write operations. Flash writes can be very slow, depending on a wide range of criteria (wear leveling, percentage of the flash storage that is in use, etc.). Brad Fitzpatrick covered this topic in his Writing zippy Android applications presentation at the 2010 Google I|O conference.
From a network standpoint, the emulator can be faster than actual hardware, because WiFi or wired Ethernet hooked up to broadband will typically be faster than a mobile data connection.
Yes true the emulator is slower than a real device. I have quite a decent development computer and it still is slower.
Here are my specs.
CPU: AMD Phenom X4 940BE (3GHz)
RAM: 8GB Corsair (800MHz)
GFX: Nvidia 9800 GTX+
MBD: Asus M3A78T
HDD: WesternDigital Velociraptor SATA2 (10k RPM)
OS: Ubuntu Lucid Lynx 64bit
And still it is quite slow compared to a real device.
Quick answer. I have found the emulator to be slower than real devices, even on my relatively fast PC.
if you install a SSD (solid State Drive) that will help a lot. i can see that you cpu and ram are decent but the simulator is pretty heavy (lots of rendering .. etc) and a faster Disk can be very helpful.