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.
Related
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.
Is there any benchmark tests results comparing this two emulators ?
I know that Genymotion is seems to be more faster when loading and rebooting the emulator,
but is there any tests show result like, Camera, GPS, networking and etc. ?
Have a look here for some informal benchmark comparisons. However, take these with a grain of salt because benchmark scores will vary greatly depending on the host system.
As for the items you want benchmarks for, not sure that camera/gps can even be benchmarked (what would you test), and networking is perfect since it uses VirtualBox, which has always had great virtual network support.
As a graphics/game developer, I find Genymotion unparalleled for running OpenGL code - on Genymotion it runs much smoother framerate wise, than using an x86+HAXM+HW GPU android emulator. Also, the integration of Google Apps/Services in Genymotion is fantastic.
Compatibility is the only downside, since Genymotion only provides v4.1+ images there is no way to test compatibility on older android versions - but for these tests I just use the standard android emulator (which is fine since it is not as frequent as normal testing).
Update: As of January 2014, Genymotion supports Android v2.3.7 as well as v4.3 (with v4.4 in preview). This means it now covers all relevant android versions except Froyo (v2.2), which at this time accounts for only 1-2% of all devices :)
I've been investigating whether to use Genymotion, with a particular focus on running automated Robotium tests.
The Genymotion startup time is around 5 seconds (compared to at least 30 seconds for the Android emulator). Genymotion also runs Robotium tests visibly faster, and with a smoother UI.
However, be warned there are some noticable differences between Genymotion and the default Android emulators:
You cannot use the special 10.0.2.2 IP address with Genymotion to access localhost on the machine you are running the emulator from. This means for local tests you may need to explicitly configure the IP address of the machine the emulator should connect to.
The difference in emulator speeds will expose timing issues in your tests. The most common one is list views needing to load their data.
I think that some Robotium Solo utilities might behave slightly differently between Genymotion and the default Android emulators. On Genymotion, I vaguely recall some problems with searchText(String) scrolling my screen to the bottom, even when the text I am searching for is already in view. However I suspect this was just another symptom of timing issues than anything being fundamentally different though (in that particular case you could always call searchText(String, true) to prevent the scrolling).
Use Android Emulator
I've personally tried both and android emulator is way better.
You just have to configure the emulator right.
My use case is mostly to manual test things here and there and run automation tests. I've benchmarked them both, android emulator is faster when running tests.
Almost all the sensors are present in android emulator and you also get an awesome command line tool with it.
For more detail, check out my blog benchmarking this.
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 pondering the idea of a Wine-ish compatibility layer on Android.
The idea is to run Symbian apps on it as both OSes share ARM hardware.
I have no knowledge of Symbian but I think that given the hardware capabilities of Android devices this could be done with less effort than Wine's windows emulation.
What would be the most significant difference to overcome in this emulator? (threading, storage, ...)
The real problem is not going to be code execution, but the API's to do things like graphics, interact with hardware, accept input, etc. If you have documentation of the original and android has the capability, API translation layers would be possible.
But android's security model outright prevents a number of things that are possible on other phone platforms, and combined with it's "java apis only" allows only inefficient means of doing things that can be done more efficiently on others.
This is of course all about application-level emulation/api translation. If you are willing to modify the android platform itself, supporting just about anything else for which you have documentation (and licensing?) within the hardware capability of the device should be possible.
Hardware capabilities of a device have nothing to do with complexity of an emulator to be hosted. It depends on Symbian's design and complexity.
And, even more, licencing. Even if one could make a Symbian emulator for Android, its legality would be questioned.
It's difficult to answer your question in detail, but since Symbian is open sourced (and Android too), if you've got the time, it shouldn't be too hard to see what sets them apart.
QT is used for the latest symbian OS, and has been ported to Android, you could write apps in QT build for each platform
the problem for writing an emulatir are variouss.
If the Symbian apps are written in in an interpreter language like Basic or similar then an emulator couldn't be too difficult to write. I did such stuff once to make the same code run on linux and windows, and I used a translation API for all calles coming from the software directed to UI, input/output.
I wound guess that the UI capabilities of Symbian are a subset of the Android functions so it would be not too difficult to write a WINE alike thing or an interpreter that runs the Symbian code on different hardware - IF it is only in high language.
But be aware there could be some machine code in the appps and that is processor specific. Most of the Android tabs nowadays run on Tegra, Tegra2 or (soon) on Tegra3, some may run on StrongArm or Arm, some may run on Intel Atom (x86 architechture), so this might get more or less impossible if the CPU isn't binary compatible like ARM / ATOM. Then you need to emulate the CPU as well and that might eat so much performance that you need a 4-5 times stronger machine to run that stuff smoothly.
It won't be too difficult to crack Android to execute Linux-alike binaries, but for sure this "mod" will affect the ability to use or download stuff from regular appstores.
With some apps you might have even more headache, e.G. my MP3 player from Korea runs on Strongarm, but it also executes Flash games from various sources. When there is no Flash player - and Google announced something like dropping support for Adobe Flash - it won't be usable.
The "most wanted" is obviously the Ovi Maps, probably that stuff could be easily converted to another app having offline navigation capability :-) People wrote "Gaia" some years ago, an open source viewer for Google Earth (and later forced to give up) so it can't bee too difficult to realize at least this.
I have a Symbian based phone with a ARM Cortex-A8 processor (SonyEricsson Vivaz) and was thinking on how hard would it be to try and port the Android OS for it. Obviously Android runs on a myriad of devices with different hardware so I imagine it shouldn't be too hard to adapt it to SE hardware. Could some one give me a clue where to start or if this is even undertakable...
How much information do you have about the hardware in the phone ? Are you starting completely from scratch ?
Porting Android is not simple task. First thing is to have Linux running (preferably 2.6.32 for more compatibility with the latest releases of AOSP.
If you can find a kernel that can run on your phone, that's one big step. After that, you want make sure that the peripherals you want to use also have the right drivers : touch interface, LCD display, SD card, audio, video. The ones that are probably most difficult will be wifi, radio (GSM) and power management module.
If you get that far, you don't have that much to go anymore, a few more changes in the kernel needed for Android, be able to compile Android correctly file system, hook up a few things like buttons and correctly interface with the drivers mentioned above...
But overall, definitely not an easy task (IMHO).