What resource configuration settings does Ruboto require in Google's or another Android emulator (whichever emulator is fastest)?
Answers exist for efficiently setting up Google's Android emulator, but they don't consider Ruboto. The Ruboto site doesn't discuss setting up an emulator.
Ruboto apps work as regular Android apps, but add the JRuby jars which enable running your Ruby code. Overall you don't need any special settings for Ruboto apps vs Java Android apps.
Ruboto apps, like all JRuby apps, use more memory and like more CPU than plain Java apps. Giving your emulator more heap using the "Max VM application heap size" will make development easier, but you need to keep in mind that the settings for the target devices of your users may vary. I use a value of 48. Besides that you can set your "Device ram size" to 512 to ensure enough memory total.
Since Android 3, api level 11, your app can request more memory in the AndroidManifest.xml using the android:largeHeap="true" attribute of the application tag. This is automatically set for you by the Ruboto generators, but you can verify that is is set for your application. By setting this attribute to "true", your app can grow a heap of 256 MB.
Related
When building Android,
lunch
possible images are:
...
5. aosp_x86-eng
6. aosp_x86_64-eng
...
16. mini_emulator_x86-userdebug
17. mini_emulator_x86_64-userdebug
...
What is exactly mini_emulator? What is the difference between mini_emulator and aosp_x86?
You can find the configurations here:
build/make/target/product/aosp_x86.mk
build/make/target/product/aosp_x86_64.mk
device/generic/mini-emulator-x86/mini_emulator_x86.mk
device/generic/mini-emulator-x86/mini_emulator_x86_64.mk
The names of these configurations mean:
aosp means a full-featured Android. Sometimes also refered to as Generic System Images.
mini means a reduced Android.
emulator means that this Android is meant to be run in the qemu-emulator.
x86 and x86_64 describe the architecture.
eng means
Development configuration with additional debugging tools
userdebug means
Like user but with root access and debug capability; preferred for debugging
I am trying to close test a flutter app but I keep getting the error ----
"This release is not compliant with the Google Play 64-bit requirement
The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code: 21.
Include 64-bit and 32-bit native code in your app. Use the Android App Bundle publishing format to automatically ensure that each device architecture receives only the native code it needs. This avoids increasing the overall size of your app. Learn More"
I tried building it in 64 and 32 bit apk's and uploading them per this article - https://medium.com/#truongsinh/flutter-android-64-bit-so-what-the-fuss-15da6f8e3a46
but its still throwing the error. Whats the solution for this?
You can use codemagic and forgot all the things about upload your app to Google Play or AppStore manually
I'm using Android Studio 2.3.3 and I need to test my app on an emulator without Google Play Services. I know that it was pretty easy to create one using the old device manager (as described in this question), but I can't figure out how to do it with the new one.
The SDK Manager tells me that the system images that I want/need (API level 25) are installed:
Android Wear Intel x86 Atom System Image
Google APIs Intel x86 Atom System Image
At the "Select a system image" step for my new virtual device, only images with the Google APIs are presented under the "Recommended" tab. I've checked "x86 Images" and "Other Images" but no options without Google Play Services are to be found anywhere. I've also looked through all the settings options available at the "Verify Configuration" step without finding anything useful.
Does anyone know how to do this, or is it perhaps in fact no longer possible?
I am trying to emulate the Galaxy Note 2 which contains 2GiB RAM and some custom hardware like the s-pen and TouchWiz. I created an emulator with 2GB to start with. The emulator won't launch, in fact it is crashing eclipse. I would also like to emulate multi-screen TouchWiz support. I don't see any info anywhere on emulating custom platforms like TouchWiz. Any ideas? I need a decent testing platform for the Galaxy series, but I can't even get basic android working.
edit: The Samsung dev page shows this setup: http://developer.samsung.com/forum/thread/emulator-size-for-galaxy-note-2-/77/178557
Is this a lack of available ram?
using the suggestion of manually adding "mb" behind the memory size in your configuration file (as suggested in this thread: Android: failed to allocate memory ) (located at: %USERPROFILE%/.android/avd/name-of-your-avd/config.ini) has solved the 768mb problem here!
example that now works on my win7 x64 ultimate os -with- dedicated gpu;
avd.ini.encoding=ISO-8859-1
hw.sdCard=no
hw.device.manufacturer=Google
hw.mainKeys=no
hw.lcd.density=320
hw.accelerometer=yes
hw.dPad=no
hw.cpu.arch=x86
skin.name=720x1280
abi.type=x86
hw.device.hash=1197498893
hw.trackBall=no
hw.device.name=Galaxy Nexus
hw.camera.back=none
hw.sensors.proximity=yes
hw.battery=yes
disk.dataPartition.size=512M
hw.gpu.enabled=yes
image.sysdir.1=system-images\android-18\x86\
hw.audioInput=yes
hw.sensors.orientation=yes
hw.camera.front=none
hw.gps=yes
skin.dynamic=yes
skin.path=720x1280
hw.keyboard=yes
vm.heapSize=128
hw.ramSize=2048mb
I have tested this on two machines, my desktop and laptop both running Windows 7 X64 Ultimate
The Laptop has an Intel I7-4702MQ with 12GB ram and GeForce GTX765M
The Desktop has an Intel I7-3820 with 32GB ram and has Ati 6950 in Crossfire and an Nvidia GTX560Ti (normally for physx).
The desktop only has issues in reliably starting the gpu acceleration while using crossfire, other then that i've had no issues with the emulator at all and even managed to assign 4096mb RAM with a 256VM Heap (however increasing the VM-heap above 128 seems to slowdown emulator initiation tremendously here)
On the desktop i also tested the 4096MB setup while even using a RAMDISK but this didn't increase performance too much.
Best settings overall (in my experience) in startup and responsiveness after just a few tests;
2048 with 128mb VM Heap size, gpu acceleration enabled.
Hope this helps out others!
I actually had a similar problem when running on Windows 7. When I relaunched Android studio with administrator privileges it worked. Otherwise I couldn't even open the AVD manager.
This question may be a duplicate of:
Android: failed to allocate memory
I don't presume you would NOT do this, but I'm just going to say it anyway...
Check the details of the correct answer, but especially check the comments for the correct answer.
Seriously, I hope this helps. Android and Eclipse issues have been a problem for me in the past until I learned to crush them with a Zen-like attitude and much exhaustive research and trial-and-error.
I am running the Android SDK inside a Windows XP VM in VMWare. As such, the Android Emulator takes forever to boot...
I have recently heard of another emulator -- the MotoDev. For those of you who tried both, could you tell if the MotoDev has any speed advantage over the standard Android Emulator?
I'm the Product Manager for MOTODEV Studio. There is not a separate emulator inside Studio, but rather another view of the existing emulator process that is displayed inside an Eclipse View. It's no faster than what you already have and depending on which transfer mechanism you use (native window vs. VNC), it could be up to 20% slower (native window is faster for Windows and Linux).
Now, as for why your emulator is taking forever...
The first time you start an emulator image (i.e. "AVD"), it has to recreate the entire target filesystem on your local disk. Subsequent launches will take less time.
If I understand correctly, you're letting the Android emulator pretend it's running its' file system through QEMU (Arm Emulator) inside a Windows XP pseudo-file system (VMWare Disk Image) that's running on whatever host operating system you have (your OS). That's a lot of file system manipulation going on. If you can reduce the file system mapping, you're going to see speed improvements. Can you map the Windows Android SDK into a real folder on your native file system? Removing that layer of abstraction is going to speed things up.
Good luck!
Eric