I need to do a lot of android testing where the device I use has to be ARM based. While it is possible to create these devices in the default android emulator they are of course very slow on my x86 development machine.
A lot of this testing runs headless and automatically so I thought about setting up an ARM server and emulate the devices there in the hope that the performance would be better. While looking around I realized that there is nearly no information about this. Is it possible to run an android emulator (ether the one provided with the SDK or any other) on a ARM machine to get higher performance for the virtual devices?
This is actually a very good question.
Some cloud services like Amazon are providing the arm based machines. With those machines, we can run android emulators in cheap price.
Google doesn't provide the android emulator binary for arm.
But you can build those emulator binaries from AOSP. You have to do some work such as editing of cross-compile build files, adding target directories and building related third party libraries in arm architecture.
If you need any further information, I would attach detailed technical tips or step-by-step manuals.
Related
I want to test Android Vulkan samples under Android Studio in MS WIndows 10
using this manual https://developer.android.com/ndk/guides/graphics/getting-started
I cannot do it because of the error
Device supports x86, but APK only supports armeabi-v7a
I have tried all options suggested here What is the reason for the error "Device supports x86, but APK only supports armeabi-v7a" but it does not work.
I have following Virtual Devices
Even if I use armeabi-v7a I cannot start app. And it is EXTREMLY slow.
Please help me to use clear steps to get working Vulkan samples under x86 images of Android. Thanks!
There are a couple different problems here:
First, the "device supports x86_64, x86, but APK only supports armeabi-v7a" means exactly what it sounds like: you've got an emulator that only supports 32-bit and 64-bit x86 instruction sets, but the native code in your APK is only compiled for 32-bit ARM. Emulating x86 devices is much faster since they can run in a virtual machine (the host CPU is actually executing emulator instructions directly, instead of having to translate them one by one in software). Configure your project to build native code for x86 in addition to armeabi-v7a.
Second, when using an ARM emulator, or if you fix the first problem and run on an x86 emulator, I don't think the Android emulator emulates a Vulkan-capable GPU yet. So you should be able to create a Vulkan instance, but vkEnumeratePhysicalDevices should return a count of zero available physical devices.
You don't give any details about "cannot start app": do you see anything in the log? Are you able to create an instance? Or is there some other completely unrelated problem before you even get to that point? Nobody can help you with that without more details.
Okey, BlueStacks is a bit slow on my pc, so I read somewhere in the internet that Genymotion is a bit faster then BlueStacks. Then I downloaded Genymotion and installed it. And after a lot of complex steps I finally understood that I need ARM translation and Google app for playing Android games. Now, I can understand that Google app is needed for getting the play store. But I am still in the dark about the 'ARM translation'. Why is it needed? what does it do? what happens if I don't use the ARM translation? And lastly, what does ARM stands for?
-Thanks in advance.
ARM is a processor architecture, you can read more about it here.
Android apps are sometimes designed with X86 architecture and sometimes with ARM.
You have to install the ARM translation in order to install on your emulator apps that use ARM architecture.
It's not a must have, but a lot of apps won't work without it.
Android games generally make use of OpenGL ES which is built from the ground up to work specifically with an ARM SoC. The Android NDK itself allows game developers to optimize their software by using C/C++ and even ARM assembly code.
The GenyMotion emulators are designed to work around an Intel x86 / x64 architecture, which is why they are faster than the Android emulators. But because of that, and because they have now decided to forgo ARM translation, they cannot run games.
A standard Android emulator actually compiles Java source to dex, and dex to ARM assembly, and these ARM instructions are run on an ARM emulation called QEMU. This makes the Android emulator incredibly slow, as it is in effect running an emulation of an ARM processor on top of an Intel-Windows machine. But it is able to run games.
The Android emulators emulate, while GenyMotion is more effectively a simulation.
This question has many parts.
Some info about my system:
64-bit Ubuntu Linux
I am wondering what the stock emulator is that comes with Android Studio (A.Studio) (if indeed it has a name).
A helpful answer would include comparing this emulator with other emulators. A list of pros and cons of using each different emulator would also be helpful.
Perhaps there is a more fundamental ~thing~ about using different emulators; information on that is welcome if anything comes to mind.
Finally, i have never used an emulator besides the one that has come with Eclipse or A.Studio. What do I need to know in order to plug any emulator into any IDE? I have had issues with IDEs being "fragile" and breaking frequently, FYI.
You can use genymotion, for fast speed the quality, both for the eclipse and Android studio, get it here.
Also you can set up the Google play service for using Google Maps and downloading apps from Google play store.
Get the package and how it use it , please refer to here.
The emulator used by Android Studio is the exact same one used with Eclipse. It is in fact included with the Android SDK (which is in turn included in Android Studio) and used by various development environments.
The way it works depends on what kind of system image you use it with. For most recent Android versions, there are 2-4 different system images - arm, arm 64-bit, x86, and x86 64-bit (the 64-bit ones are Lollipop only, and fairly experimental at this stage of the game [early 2015]).
There are also Google API versions of these images (they include various Google apps such as Google Play Services) which can be used if these components are needed by your app.
For development purposes, the x86 system images are your best bet as performance is vastly improved by the emulator not having to emulate the ARM architecture - you need to use HAXM (by intel, also available in the Android SDK) to get any real speed benefits with x86 images though. The emulator also provides GPU acceleration (it must be manually enabled for each emulator device) which allows it to use your physical GPU for rendering instead of emulating these operations in software.
The way the development environment (Android Studio) connects to the emulator is via ADB (Android Debug Bridge). This means that it can work with virtually any emulator (such as Genymotion, which runs via VirtualBox). However, there is native support for using the Android Emulator from within Android Studio (this is configured by selecting emulator in the Run/Debug configuration)...when using another emulator (such as Genymotion) you should select USB device (in Run/Debug configuration) and make sure that the ADB instance is connected to your emulator via TCP (Genymotion does this for you automatically at startup).
This should give you enough information and I will not re-post all the various instructions on how to do any of the above as they have been posted as answers to various questions here on SO.
I've seen in the Android Developers page that the SDK requires an x86 computer. Is there someway to use an ARM Based linux machine running Ubuntu to develop for Android?
This depends to some degree on what you mean by "to develop for android".
There are a number of scripting tools and frameworks which can be used to create applications on android, without actually compiling any java code. Some of these are intended even for development on the android device itself.
In terms of traditional SDK apps, most of the android toolchain is open source and potentially build-able for any posix-ish platform. The problem is the java jdk - you would need to obtain something to fill that role in the toolchain which would run on your ARM system. Something which compiles another language to dalvik opcodes and thus bypasses the need for the jdk could also be a possibility.
Presumably porting the NDK gcc & binutils along with the android packager is possible, which could make available either the official "native activity" option of more recent android releases, or some custom solution in which the java portion is a pre-generated wrapper and only native code is written for the interesting parts that would have to change during routine app development.
Finally, we aren't far from the point where it would theoretically be possible to emulate an "older" x86 system on a cutting-edge ARM one; potentially the x86 jdk could be run in such a virtual environment, albeit inefficiently.
Since this answer was written, solutions for doing Android Java->Dalvik development on the device itself have become available. As these work at least on ARM-based Android devices, that would qualify as developing for Android on an "ARM based computer". Presumably the same ideas could be applied to an ARM-based netbook or "chromebook" type of system.
I know I could use my Desire Z as a test phone, but what if I want to develop for 3.0 Honeycomb? What's an alternative for the emulator since it's so slow?
http://www.bluestacks.com/
This site has been getting some press recently. It seems that they are going to launch a windows runnable version of android later this year. This will be another alternative to using devices or emulators for testing I would imagine.
A general solution to the slowness of processor-emulation based emulators is to run a build of the embedded environment compiled for the same processor and general architecture as the hosting machine, in virtual machine software which can run most of the code native, and only has to trap and emulate privileged/hardware-related actions.
In other words, you run the x86 build of android in VirtualBox, vmware, or whatever, and dispense with the overhead of emulating an arm processor.
In quick web searching I'm not getting a confident answer if there's a working build of Honeycomb for x86 yet, but presumably there will be a build of that or a later android version at some point.
The only alternative is to have a physical device with Android 3.0 imaged on it.
Try this one for a change it actually provides an eclipse plugin and it uses cloud i guess it is faster than the emulator comes with android by default http://www.genymotion.com/features/