Status Update
Comments
ra...@android.com <ra...@android.com> #2
Random suggestion: Could you try editing the hardware properties of the AVD and use a lower Device RAM Size? E.g. try 512 or 768 instead of 1024.
If you're editing the .android/avd/*/config.ini directly, it's the line hw.ramSize=1024
If you're editing the .android/avd/*/config.ini directly, it's the line hw.ramSize=1024
ga...@gmail.com <ga...@gmail.com> #3
I'm seeing exactly the same issue Windows 7 Enterprise 64 bit. I've tried taking hw.ramSize all the way down to 128 with no effect. However I am only seeing this issue for the WXGA* skins. WVGA* skins work fine with Android 4.1 for me.
sa...@samkelleher.com <sa...@samkelleher.com> #4
Same issue, regardless of memory size. Windows 7 x64 Ultimate. Just upgraded the SDK to version 20 from 19.
I solved this issue by manually setting the resolution, so instead of selecting the WXGA* (in my case WXGA800) set the resolution to the equivalent value (1280x800 for example). The AVD then starts normally.
I solved this issue by manually setting the resolution, so instead of selecting the WXGA* (in my case WXGA800) set the resolution to the equivalent value (1280x800 for example). The AVD then starts normally.
an...@gmail.com <an...@gmail.com> #5
I experienced the same issue. Setting resolution manually works!
Would love to downgrade the SDK because I also have a probably related issue with WVGA800 on Android 4.0 - emulator runs but app does not even launch due to out of memory error (there is no problem with 4.0.3 and WVGA800 however). Again - if I set resolution manually - the app launches without out of memory error.
On SDK 18 I did not have any problems with these skins.
Would love to downgrade the SDK because I also have a probably related issue with WVGA800 on Android 4.0 - emulator runs but app does not even launch due to out of memory error (there is no problem with 4.0.3 and WVGA800 however). Again - if I set resolution manually - the app launches without out of memory error.
On SDK 18 I did not have any problems with these skins.
je...@gmail.com <je...@gmail.com> #6
I downgraded my tools to get around this problem for now. As noted above, I am able to work with tools version 19 and platform-tool version 11. I do not know what version of platform-tools goes with tools version 18, for those that need this version, so I have listed both versions 10 and 11 of platform-tools. Make sure that adb.exe is not running when you replace the files manually.
https://dl-ssl.google.com/android/repository/tools_r19-windows.zip
https://dl-ssl.google.com/android/repository/tools_r19-linux.zip
https://dl-ssl.google.com/android/repository/tools_r19-macosx.zip
https://dl-ssl.google.com/android/repository/tools_r18-windows.zip
https://dl-ssl.google.com/android/repository/tools_r18-linux.zip
https://dl-ssl.google.com/android/repository/tools_r18-macosx.zip
https://dl-ssl.google.com/android/repository/platform-tools_r11-windows.zip
https://dl-ssl.google.com/android/repository/platform-tools_r11-linux.zip
https://dl-ssl.google.com/android/repository/platform-tools_r11-macosx.zip
https://dl-ssl.google.com/android/repository/platform-tools_r10-windows.zip
https://dl-ssl.google.com/android/repository/platform-tools_r10-linux.zip
https://dl-ssl.google.com/android/repository/platform-tools_r10-macosx.zip
je...@gmail.com <je...@gmail.com> #7
This problem still happens with tools version 20.0.1 and platform-tools version 13. It still appears to be caused by starting up OpenGLES emulation even when "GPU emulation" is set to no (as noted in log provided in the initial post). I see the same error when I take tools version 19 and platform-tools version 11, which work for me with their default settings of "GPU emulation" set to no, and set "GPU emulation" to yes.
m....@gmail.com <m....@gmail.com> #8
Same error here on Windows Platforms.
I get the crash when the emulator tries to initialize OpenGl (even when set to no). It crashes on my desktop (ATI Raddeon driver), it crashes in every Windows VM I have (with VMWare hardware accelerated drivers). It works on my MacBook Air (Google seems to like Apple :)).
Dump in a VMWare Windows 7 (4 GB):
emulator: registered 'boot-properties' qemud service
emulator: Adding boot property: 'dalvik.vm.heapsize' = '48m'
emulator: Adding boot property: 'qemu.sf.lcd_density' = '213'
emulator: Adding boot property: 'qemu.hw.mainkeys' = '0'
emulator: Adding boot property: 'qemu.sf.fake_camera' = 'back'
emulator: nand_add_dev: cache,size=0x4200000,file=C:\Users\Markus\.android\avd\Nexus7.avd/cache.img
emulator: Initializing hardware OpenGLES emulation support
extension WGL_ARB_make_current_read was not found
extension WGL_EXT_swap_control was not found
Failed to create pbuf surface for FB 0x3004
emulator: Can't start OpenGLES renderer?
emulator: WARNING: Could not initialize OpenglES emulation, using software renderer.
emulator: Kernel parameters: qemu.gles=0 qemu=1 console=ttyS0 android.qemud=ttyS1 android.checkjni=1 ndns=3
Failed to allocate memory: 8
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I get the crash when the emulator tries to initialize OpenGl (even when set to no). It crashes on my desktop (ATI Raddeon driver), it crashes in every Windows VM I have (with VMWare hardware accelerated drivers). It works on my MacBook Air (Google seems to like Apple :)).
Dump in a VMWare Windows 7 (4 GB):
emulator: registered 'boot-properties' qemud service
emulator: Adding boot property: 'dalvik.vm.heapsize' = '48m'
emulator: Adding boot property: 'qemu.sf.lcd_density' = '213'
emulator: Adding boot property: 'qemu.hw.mainkeys' = '0'
emulator: Adding boot property: 'qemu.sf.fake_camera' = 'back'
emulator: nand_add_dev: cache,size=0x4200000,file=C:\Users\Markus\.android\avd\Nexus7.avd/cache.img
emulator: Initializing hardware OpenGLES emulation support
extension WGL_ARB_make_current_read was not found
extension WGL_EXT_swap_control was not found
Failed to create pbuf surface for FB 0x3004
emulator: Can't start OpenGLES renderer?
emulator: WARNING: Could not initialize OpenglES emulation, using software renderer.
emulator: Kernel parameters: qemu.gles=0 qemu=1 console=ttyS0 android.qemud=ttyS1 android.checkjni=1 ndns=3
Failed to allocate memory: 8
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
ed...@gmail.com <ed...@gmail.com> #9
Same issue here on Windows 7 x64. Rather annoying to be honest..
da...@gmail.com <da...@gmail.com> #10
[Comment deleted]
da...@gmail.com <da...@gmail.com> #11
Strangely i can get it to work if I combine:
1) Typing in the resolution manually rather than picking WXVGA720 or 800
2) Adding the MB after 1024 ram size and then it booted.
http://stackoverflow.com/questions/5969067/android-failed-to-allocate-memory
1) Typing in the resolution manually rather than picking WXVGA720 or 800
2) Adding the MB after 1024 ram size and then it booted.
je...@gmail.com <je...@gmail.com> #12
It appears that this issue is closely related to issue 36949180 (http://code.google.com/p/android/issues/detail?id=36080 ). When using the WXGA800 skin the emulator ignores any custom RAM value and always uses 1024. As noted in the other issue, specifying the memory from the commandline to a lower value (in my case 896) works. The earlier comments about using a different skin and manually setting the resolution probably got around this problem because the other skins default to a lesser amount of RAM.
@Comment 10 - The reason adding "MB" after the RAM size worked is not why you think. The "MB" is not recognized by the emulator so it instead uses 256 no matter what your value is. You can verify this by running the emulator from the commandline (emulator -avd YOUR_AVD_NAME -verbose) and looking at the hw.ramSize line.
@Comment 10 - The reason adding "MB" after the RAM size worked is not why you think. The "MB" is not recognized by the emulator so it instead uses 256 no matter what your value is. You can verify this by running the emulator from the commandline (emulator -avd YOUR_AVD_NAME -verbose) and looking at the hw.ramSize line.
va...@gmail.com <va...@gmail.com> #13
Comment5 you are my saver!!!!! Before last update my life was so quite and simple(except app developing :) which fun but sometimes such a head ache). Since last update I was frustrated. Tons of links, forums,messages,solutions, reinstalls, ram change, WX/VGA changes, running from cmd (this actually worked for me but with some minor issues).
As soon I saw your post and downgrade option, my life is back again nice and simple.
THANK YOU SO MUCH. Downgraded to tools 19r and platform-tools 11r
As soon I saw your post and downgrade option, my life is back again nice and simple.
THANK YOU SO MUCH. Downgraded to tools 19r and platform-tools 11r
sh...@gmail.com <sh...@gmail.com> #14
Comment5. cc: Comment12.
Am using this ground to say a BIG THANK to u 2.U make my day for providing me a wonderful solution to my problem....
THANK YOU SO MUCH. Downgraded to tools 19r and platform-tools 11r
Add a comment
Am using this ground to say a BIG THANK to u 2.U make my day for providing me a wonderful solution to my problem....
THANK YOU SO MUCH. Downgraded to tools 19r and platform-tools 11r
Add a comment
te...@gmail.com <te...@gmail.com> #15
This is still present in 20.03 of the tools. I can confirm that entering the resolution manually allows the VM to start without crashing, although I honestly cannot fathom how a bug like this has existed since June without being fixed in one of the four releases subsequent to its report.
vi...@gmail.com <vi...@gmail.com> #16
I'm getting these errors here:
Starting emulator for AVD 'AVDEmulator'
extension WGL_ARB_make_current_read was not found
could not load func glBindBuffer
could not load func glBlendEquationSeparate
could not load func glBufferData
could not load func glBufferSubData
could not load func glDeleteBuffers
could not load func glGenBuffers
could not load func glGetBufferParameteriv
could not load func glIsBuffer
could not load func glStencilFuncSeparate
could not load func glIsProgram
emulator: warning: opening audio input failed
could not load func glIsShader
could not load func glVertexAttrib1f
could not load func glVertexAttrib1fv
could not load func glVertexAttrib2f
could not load func glVertexAttrib2fv
could not load func glVertexAttrib3f
could not load func glVertexAttrib3fv
could not load func glVertexAttrib4f
could not load func glVertexAttrib4fv
could not load func glVertexAttribPointer
could not load func glDisableVertexAttribArray
could not load func glEnableVertexAttribArray
could not load func glGetVertexAttribfv
could not load func glGetVertexAttribiv
could not load func glGetVertexAttribPointerv
could not load func glUniform1f
could not load func glUniform1fv
could not load func glUniform1i
could not load func glUniform1iv
could not load func glUniform2f
could not load func glUniform2fv
could not load func glUniform2i
could not load func glUniform2iv
could not load func glUniform3f
could not load func glUniform3fv
could not load func glUniform3i
could not load func glUniform3iv
could not load func glUniform4f
could not load func glUniform4fv
could not load func glUniform4i
could not load func glUniform4iv
could not load func glUniformMatrix2fv
could not load func glUniformMatrix3fv
could not load func glUniformMatrix4fv
could not load func glAttachShader
could not load func glBindAttribLocation
could not load func glCompileShader
could not load func glCreateProgram
could not load func glCreateShader
could not load func glDeleteProgram
could not load func glDeleteShader
could not load func glDetachShader
could not load func glLinkProgram
could not load func glUseProgram
could not load func glValidateProgram
could not load func glGetActiveAttrib
could not load func glGetActiveUniform
could not load func glGetAttachedShaders
could not load func glGetAttribLocation
could not load func glGetProgramiv
could not load func glGetProgramInfoLog
could not load func glGetShaderiv
could not load func glGetShaderInfoLog
could not load func glGetShaderSource
could not load func glGetUniformfv
could not load func glGetUniformiv
could not load func glGetUniformLocation
could not load func glShaderSource
could not load func glStencilMaskSeparate
could not load func glBindBuffer
could not load func glBlendEquationSeparate
could not load func glBufferData
could not load func glBufferSubData
could not load func glDeleteBuffers
could not load func glGenBuffers
could not load func glGetBufferParameteriv
could not load func glIsBuffer
Starting emulator for AVD 'AVDEmulator'
extension WGL_ARB_make_current_read was not found
could not load func glBindBuffer
could not load func glBlendEquationSeparate
could not load func glBufferData
could not load func glBufferSubData
could not load func glDeleteBuffers
could not load func glGenBuffers
could not load func glGetBufferParameteriv
could not load func glIsBuffer
could not load func glStencilFuncSeparate
could not load func glIsProgram
emulator: warning: opening audio input failed
could not load func glIsShader
could not load func glVertexAttrib1f
could not load func glVertexAttrib1fv
could not load func glVertexAttrib2f
could not load func glVertexAttrib2fv
could not load func glVertexAttrib3f
could not load func glVertexAttrib3fv
could not load func glVertexAttrib4f
could not load func glVertexAttrib4fv
could not load func glVertexAttribPointer
could not load func glDisableVertexAttribArray
could not load func glEnableVertexAttribArray
could not load func glGetVertexAttribfv
could not load func glGetVertexAttribiv
could not load func glGetVertexAttribPointerv
could not load func glUniform1f
could not load func glUniform1fv
could not load func glUniform1i
could not load func glUniform1iv
could not load func glUniform2f
could not load func glUniform2fv
could not load func glUniform2i
could not load func glUniform2iv
could not load func glUniform3f
could not load func glUniform3fv
could not load func glUniform3i
could not load func glUniform3iv
could not load func glUniform4f
could not load func glUniform4fv
could not load func glUniform4i
could not load func glUniform4iv
could not load func glUniformMatrix2fv
could not load func glUniformMatrix3fv
could not load func glUniformMatrix4fv
could not load func glAttachShader
could not load func glBindAttribLocation
could not load func glCompileShader
could not load func glCreateProgram
could not load func glCreateShader
could not load func glDeleteProgram
could not load func glDeleteShader
could not load func glDetachShader
could not load func glLinkProgram
could not load func glUseProgram
could not load func glValidateProgram
could not load func glGetActiveAttrib
could not load func glGetActiveUniform
could not load func glGetAttachedShaders
could not load func glGetAttribLocation
could not load func glGetProgramiv
could not load func glGetProgramInfoLog
could not load func glGetShaderiv
could not load func glGetShaderInfoLog
could not load func glGetShaderSource
could not load func glGetUniformfv
could not load func glGetUniformiv
could not load func glGetUniformLocation
could not load func glShaderSource
could not load func glStencilMaskSeparate
could not load func glBindBuffer
could not load func glBlendEquationSeparate
could not load func glBufferData
could not load func glBufferSubData
could not load func glDeleteBuffers
could not load func glGenBuffers
could not load func glGetBufferParameteriv
could not load func glIsBuffer
ta...@gmail.com <ta...@gmail.com> #17
r20.0.3 on Win7-64.
Using 32 or 64-bit Java runtime / SDK won't change anything.
Basically, any display "skin" that adds hw.ramSize=1024 to the config.ini will cause AVD to crash. Of course, simply removing this line from the config.ini won't do either.
=> Select the resolution manually until this bug is fixed (if they ever fix it, I see it's been here for a while), and make sure to remove this ramSize from the settings.
Using 32 or 64-bit Java runtime / SDK won't change anything.
Basically, any display "skin" that adds hw.ramSize=1024 to the config.ini will cause AVD to crash. Of course, simply removing this line from the config.ini won't do either.
=> Select the resolution manually until this bug is fixed (if they ever fix it, I see it's been here for a while), and make sure to remove this ramSize from the settings.
ga...@gmail.com <ga...@gmail.com> #18
Just upgraded to SDK r21 and still seeing the exact same issue.
ya...@gmail.com <ya...@gmail.com> #19
[Comment deleted]
on...@gmail.com <on...@gmail.com> #20
[Comment deleted]
su...@gmail.com <su...@gmail.com> #21
I am using window XP , SDK version r21 and I am facing same issue. Is there any right solutions for this issue. Please check the error file for the log error.
ch...@gmail.com <ch...@gmail.com> #22
I also have this issue when RAM size is anything but 512. Starts fine with 512 but anything else on any AVD and it fails.
lc...@gmail.com <lc...@gmail.com> #23
See issue 36949180 .
pa...@gmail.com <pa...@gmail.com> #24
[Comment deleted]
ka...@gmail.com <ka...@gmail.com> #25
yup thats the one. You'd figure that would be a huge priority
pu...@gmail.com <pu...@gmail.com> #26
If you use higher resolution (like I use for emulator: 720x1280, or higher, like even FullHD, this is not an unusual mobile resolution nowadays) it's more (most?) likely to reproduce.
ma...@gmail.com <ma...@gmail.com> #27
I debugged this on my machine and here's what's going on:
---------------------------------------------------------
* The emulator needs to allocate a large, contiguous block of address space for the emulator memory.
* Version r20 of the tools added OpenGLES emulation support to the emulator (I think).
* When OpenGLES emulation is used, additional DLLs are loaded into the emulator process's address space: <android-sdk-root>\tools\lib\lib*.dll, %windir%\system32\opengl32.dll, and potentially DLLs from your video card vendor, such as atioglxx.dll.
* These DLLs are often loaded at addresses that fragment the process address space (typically 2GB for 32-bit processes). The following factors may make it more likely that address space is fragmented by these DLLs:
* Windows tries to load them at their preferred addresses (set with the linker option /base), which may not be ideally chosen for the purpose of limited address space fragmentation. Indeed, I think it is hard to figure out what a preferred address should be.
* Many of these DLLs are not built with the /dynamicbase linker option which tells Windows that it may use Address Space Layout Randomization (ASLR) to select the address of the DLL. I'm just guessing, but this may be a factor in what address Windows chooses to load the DLL.
* In particular, when I run the emulator on my system, opengl32.dll is often crammed right in the middle of a large free block of address space, making it impossible to allocate 1GB of contiguous address space for the emulator memory.
* Note that because Windows uses ASLR to load DLLs at somewhat random addresses, this explains why starting up the emulator actually works sometimes without changing anything.
Potential work-arounds
----------------------
* Disable OpenGLES emulation support by renaming <android-sdk-root>\tools\lib\libOpenglRender.dll to libOpenglRender.dll.disabled. Or,
* Reduce the amount of memory used by the emulator. Try 900MB, if that doesn't work, try 800MB, if that doesn't work, try 700MB, you get the idea.
Potential fixes
---------------
* If Google switches to a 64-bit emulator (and the developer uses a 64-bit OS), the problem will likely go away.
* Implement some hack in the emulator to coerce DLLs to load at better addresses. For example, allocate the 1GB block of memory and other large data structures before loading the OpenGLES emulation-related DLLs.
* The various DLLs should have better preferred addresses (if that's even possible to figure out) and they should be built with /dynamicbase. I experimented with this a little bit on my machine and it still wasn't enough to get the emulator reliably loading with 1GB.
---------------------------------------------------------
* The emulator needs to allocate a large, contiguous block of address space for the emulator memory.
* Version r20 of the tools added OpenGLES emulation support to the emulator (I think).
* When OpenGLES emulation is used, additional DLLs are loaded into the emulator process's address space: <android-sdk-root>\tools\lib\lib*.dll, %windir%\system32\opengl32.dll, and potentially DLLs from your video card vendor, such as atioglxx.dll.
* These DLLs are often loaded at addresses that fragment the process address space (typically 2GB for 32-bit processes). The following factors may make it more likely that address space is fragmented by these DLLs:
* Windows tries to load them at their preferred addresses (set with the linker option /base), which may not be ideally chosen for the purpose of limited address space fragmentation. Indeed, I think it is hard to figure out what a preferred address should be.
* Many of these DLLs are not built with the /dynamicbase linker option which tells Windows that it may use Address Space Layout Randomization (ASLR) to select the address of the DLL. I'm just guessing, but this may be a factor in what address Windows chooses to load the DLL.
* In particular, when I run the emulator on my system, opengl32.dll is often crammed right in the middle of a large free block of address space, making it impossible to allocate 1GB of contiguous address space for the emulator memory.
* Note that because Windows uses ASLR to load DLLs at somewhat random addresses, this explains why starting up the emulator actually works sometimes without changing anything.
Potential work-arounds
----------------------
* Disable OpenGLES emulation support by renaming <android-sdk-root>\tools\lib\libOpenglRender.dll to libOpenglRender.dll.disabled. Or,
* Reduce the amount of memory used by the emulator. Try 900MB, if that doesn't work, try 800MB, if that doesn't work, try 700MB, you get the idea.
Potential fixes
---------------
* If Google switches to a 64-bit emulator (and the developer uses a 64-bit OS), the problem will likely go away.
* Implement some hack in the emulator to coerce DLLs to load at better addresses. For example, allocate the 1GB block of memory and other large data structures before loading the OpenGLES emulation-related DLLs.
* The various DLLs should have better preferred addresses (if that's even possible to figure out) and they should be built with /dynamicbase. I experimented with this a little bit on my machine and it still wasn't enough to get the emulator reliably loading with 1GB.
vi...@gmail.com <vi...@gmail.com> #28
Even I am facing the same bug on the skin:WXGA720.
After downgrading the skin to previous and then back on same WXGA720 skin loaded the emulator normally.
Kind of unusual behaviour as downgrading the RAM didn't do any good for me.
After downgrading the skin to previous and then back on same WXGA720 skin loaded the emulator normally.
Kind of unusual behaviour as downgrading the RAM didn't do any good for me.
as...@gmail.com <as...@gmail.com> #29
Same problem with tools 24 and platform 19
pr...@google.com <pr...@google.com> #30
I could not repro the crash but ARM emulators (WXGA800 and WXGA720 skins) running API 15 (public system image) were stuck at boot animation for more than 10mins and did not proceed to homescreen
Host machine: Windows 7 Enterprise
Tools: build: aosp-emu-master-dev @ 2567801
Steps: Same as in original thread
Emulator AVD: ARM emulator running API 15
Build: sdk-eng 4.0.4 MR1 1741834 test-keys (latest public)
Skin: WXGA800
Host GPU: On
RAM: 1024MB
logcat report for emulator with WXGA800 skin here:https://paste.googleplex.com/6697909793849344
logcat report for emulator with WXGA720 skin here:
https://paste.googleplex.com/5108366825226240
Host machine: Windows 7 Enterprise
Tools: build: aosp-emu-master-dev @ 2567801
Steps: Same as in original thread
Emulator AVD: ARM emulator running API 15
Build: sdk-eng 4.0.4 MR1 1741834 test-keys (latest public)
Skin: WXGA800
Host GPU: On
RAM: 1024MB
logcat report for emulator with WXGA800 skin here:
logcat report for emulator with WXGA720 skin here:
vh...@google.com <vh...@google.com> #31
Dropping priority. There are lots of other ARM system images that are working.
vh...@google.com <vh...@google.com>
bo...@google.com <bo...@google.com> #32
just tried:
this is an annoying bug where it appears that boot-animation has taking forever but not: it actually stops after some time (less than 1minutes if using Nexus S with gpu on);
the problem looks like is in the launcher not refreshing the home screen; clicking the 'home' button does make it to show home screen.
this problem exists in both arm and x86 images. I think it is not blocking app from
running- so I lower the priority to medium: will work on it after other high priority issues.
please re-raise it if it is not the case.
this is an annoying bug where it appears that boot-animation has taking forever but not: it actually stops after some time (less than 1minutes if using Nexus S with gpu on);
the problem looks like is in the launcher not refreshing the home screen; clicking the 'home' button does make it to show home screen.
this problem exists in both arm and x86 images. I think it is not blocking app from
running- so I lower the priority to medium: will work on it after other high priority issues.
please re-raise it if it is not the case.
dr...@gmail.com <dr...@gmail.com> #34
the step to resolve Warning: requested ram_size 1536M too big, reduced to 512M
Description
SDK tools version: 20 (platform-tools 12)
Eclipse version: NA
ADT plug-in version: NA
Platform targeted by your project: NA
Version of the platform running in the emulator: 4.0.3, 4.1
STEPS TO REPRODUCE:
1.Create a new VM for either 4.0.3 or 4.1 with the WXGA800 skin
2.Leave the hardware at the default settings
3.Attempt to start the VM
EXPECTED RESULTS:
The VM should start.
OBSERVED RESULTS:
The VM does not start and produces an error.
ADDITIONAL INFORMATION:
Below is the verbose dump from the emulator. I tried setting the RAM down to a lower value (256 instead of 1024) but this did not seem to help. I noticed in the output the line "Initializing hardware OpenGLES emulation support" so I added GPU emulation and set it to "no" but this did not seem to have any affect. Even with the GPU emulation set to no the output still contained that line.
I replaced the "tools" with version 19 and the "platform-tools" with version 11 and the VMs work again.
EMULATOR LOG
emulator: found SDK root at C:\Program Files\Android\android-sdk
emulator: Android virtual device file at: C:\Users\User_Admin\.android/avd/Android_4.0.3_ARM_tablet.ini
emulator: virtual device content at C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd
emulator: virtual device config file: C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/config.ini
emulator: using core hw config path: C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/hardware-qemu.ini
emulator: Found AVD target API level: 15
emulator: found skin 'WXGA800' in directory: C:\Program Files\Android\android-sdk/platforms\android-15\skins
emulator: autoconfig: -skin WXGA800
emulator: autoconfig: -skindir C:\Program Files\Android\android-sdk/platforms\android-15\skins
emulator: found skin-specific hardware.ini: C:\Program Files\Android\android-sdk/platforms\android-15\skins/WXGA800/hardware.ini
emulator: keyset loaded from: C:\Users\User_Admin\.android\default.keyset
emulator: trying to load skin file 'C:\Program Files\Android\android-sdk/platforms\android-15\skins/WXGA800/layout'
emulator: skin network speed: 'full'
emulator: skin network delay: 'none'
emulator: autoconfig: -kernel C:\Program Files\Android\android-sdk/system-images\android-15\armeabi-v7a\/kernel-qemu
emulator: autoconfig: -ramdisk C:\Program Files\Android\android-sdk/system-images\android-15\armeabi-v7a\/ramdisk.img
emulator: Using initial system image: C:\Program Files\Android\android-sdk/system-images\android-15\armeabi-v7a\/system.img
emulator: autoconfig: -data C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/userdata-qemu.img
emulator: autoconfig: -initdata C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/userdata.img
emulator: autoconfig: -cache C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/cache.img
emulator: autoconfig: -sdcard C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/sdcard.img
emulator: Physical RAM size: 1024MB
Content of hardware configuration file:
hw.cpu.arch = arm
hw.cpu.model = cortex-a8
hw.ramSize = 1024
hw.screen = touch
hw.mainKeys = yes
hw.trackBall = yes
hw.keyboard = no
hw.keyboard.lid = no
hw.keyboard.charmap = qwerty2
hw.dPad = yes
hw.gsmModem = yes
hw.gps = yes
hw.battery = yes
hw.accelerometer = yes
hw.audioInput = yes
hw.audioOutput = yes
hw.sdCard = yes
hw.sdCard.path = C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/sdcard.img
disk.cachePartition = yes
disk.cachePartition.path = C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/cache.img
disk.cachePartition.size = 66m
hw.lcd.width = 1280
hw.lcd.height = 800
hw.lcd.depth = 16
hw.lcd.density = 160
hw.lcd.backlight = yes
hw.gpu.enabled = no
hw.camera.back = emulated
hw.camera.front = none
vm.heapSize = 48
hw.sensors.proximity = yes
hw.sensors.magnetic_field = yes
hw.sensors.orientation = yes
hw.sensors.temperature = yes
kernel.path = C:\Program Files\Android\android-sdk/system-images\android-15\armeabi-v7a\/kernel-qemu
kernel.parameters = android.checkjni=1
disk.ramdisk.path = C:\Program Files\Android\android-sdk/system-images\android-15\armeabi-v7a\/ramdisk.img
disk.systemPartition.initPath = C:\Program Files\Android\android-sdk/system-images\android-15\armeabi-v7a\/system.img
disk.systemPartition.size = 200m
disk.dataPartition.path = C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/userdata-qemu.img
disk.dataPartition.size = 200m
.
QEMU options list:
emulator: argv[00] = "./emulator-arm.exe"
emulator: argv[01] = "-android-hw"
emulator: argv[02] = "C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/hardware-qemu.ini"
Concatenated QEMU options:
./emulator-arm.exe -android-hw C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/hardware-qemu.ini
emulator: registered 'boot-properties' qemud service
emulator: nand_add_dev: system,size=0xc800000,initfile=C:\Program Files\Android\android-sdk/system-images\android-15\armeabi-v7a\/system.img
emulator: mapping 'system' NAND image to C:\Users\User_A~1\AppData\Local\Temp\\AndroidEmulator\TMP50AE.tmp
emulator: rounding devsize up to a full eraseunit, now c810000
emulator: nand_add_dev: userdata,size=0xc800000,file=C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/userdata-qemu.img
emulator: rounding devsize up to a full eraseunit, now c810000
emulator: registered 'boot-properties' qemud service
emulator: Adding boot property: 'dalvik.vm.heapsize' = '48m'
emulator: Adding boot property: 'qemu.sf.lcd_density' = '160'
emulator: Adding boot property: 'qemu.hw.mainkeys' = '1'
emulator: Adding boot property: 'qemu.sf.fake_camera' = 'back'
emulator: nand_add_dev: cache,size=0x4200000,file=C:\Users\User_Admin\.android\avd\Android_4.0.3_ARM_tablet.avd/cache.img
emulator: Initializing hardware OpenGLES emulation support
emulator: Kernel parameters: qemu.gles=0 qemu=1 console=ttyS0 android.qemud=ttyS1 android.checkjni=1 ndns=-1
Failed to allocate memory: 8
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.