Problema del emulador HelloAndroid

Resumen
(Puede ver los detalles completos debajo de estos pasos resumidos).

1. Desinstalar / Reinstalar Android SDK a la carpeta de C: \ (sin espacios en la ruta de acceso)
2. Vuelva a crear el AVD.
3. Establezca la variable de entorno PATH para las nuevas ubicaciones de la carpeta SDK de Android
4. Desinstale / vuelva a instalar el complemento ADT de Android en Eclipse.
5. Configure la ubicación del SDK de Android en Eclipse.
6. Reiniciar (para reducir la utilización de la CPU)
7. Ejecute el emulador desde la línea de comandos y configúrelo para que utilice todas las CPU con prioridad Alta o "Tiempo real". Anote el uso de la CPU.
8. Abra Eclipse y ejecute la aplicación.

Detalles
Pasé dos días recibiendo el emulador para ejecutar la aplicación HelloAndroid. En mi caso, el problema podría haber sido una combinación de un problema con la instalación de SDK de Android y un problema de rendimiento de la CPU. Creo que algo estaba haciendo que el emulador funcione muy lentamente haciendo que el emulador parezca colgar. Mi PC es un Windows 7 de 64 bits de 6 GB Intel i7 multi-core PC. El Administrador de tareas muestra 8 CPUs en mi PC en la etiqueta de rendimiento.

Mi síntoma fue el Android 2.2 AVD en el emulador parecía colgar cuando el nimated "Android" texto estaba mostrando en la pantalla. La pantalla de inicio nunca aparecerá. Este escenario sucedió una y otra vez. Yo a menudo esperar 30 minutos o 45 minutos en vano.

Mi ambiente:

• Android SDK Revisión 12
• Android 2.2 AVD
• Windows 7 de 64 bits
• IDE de Eclipse para desarrolladores de Java Indigo Release ID de compilación 20110615-0604
• CPU Intel Core i7 de varios núcleos, 6 GB, 1.6 GHz

Intenté iniciar el emulador desde la línea de comandos sin iniciar Eclipse en el símbolo del sistema y eso no ayudó. El emulador todavía colgaba. Me di cuenta de que el Administrador de tareas mostró mi caja de 50% de uso de la CPU que parecía bastante alto. La CPU 0 se fijó al 100%.

Esto es lo que lo arregló.

Desinstalé el SDK de Android R12 y lo reinstalé de la raíz de C: en C: \ android-sdk. Había experimentado previamente problemas porque el SDK de Androide estaba situado en la carpeta de los "archivos C: \ Program"; El SDK tiene un error que no puede controlar el espacio en la ruta de acceso . Ejecuté "uninstall.exe" de la carpeta Android SDK para hacer la desinstalación. La desinstalación tomó más tiempo que la instalación.

He añadido "C: \ android-sdk \ tools \; C: \ android-sdk \ platform-tools \" a la variable de entorno PATH.

Entonces suprimí el AVD usando SDK Manager y lo recreé.

Desinstalé el ADT Plugin para Eclipse, reinicié Eclipse, luego reinstalé el ADT Plugin, luego cerré Eclipse.

He reconfigurado Eclipse con la nueva ruta de SDK de Android (Ventana> Preferencias> Android> Ubicación de SDK).

En la ficha Procesos del Administrador de tareas, habilité "Mostrar procesos de todos los usuarios". Luego, pulsé con el botón derecho "emulator-arm.exe * 32" y luego presioné "Set Affinity …" y noté que el emulador estaba configurado para usar sólo la CPU 0, así que lo cambié para usar todas las CPU. También establezco el emulador a prioridad "Tiempo real".

Observando un 50% de uso de la CPU, reiniciado.

Después de reiniciar, empecé el emulador usando la línea de comandos:

 emulator @Android22 

Android22 es el nombre de mi AVD. Utilicé el encargado de la tarea para fijar la afinidad para que el emulador utilice todas las CPU y fijara la prioridad a alto. Mi uso de la CPU ahora era cerca de 13%, sobre todo debido al emulador. El emulador tomó unos 3 minutos para mostrar la pantalla de inicio. ¡Hurra!

A continuación, abrió Eclipse con la aplicación HelloAndroid y la aplicación se ejecutó correctamente en el emulador.

He escrito en detalle lo que hice porque los dos últimos días han sido un verdadero dolor. Me di cuenta de varios mensajes sobre este tema con muchas personas que no parecen tener éxito. He realizado los pasos mencionados en varios puestos, pero no encontrar un lugar que describió todo el proceso.

Buena suerte. Espero que esta información ayude a alguien.

Está cargando. Puede comprobar el progreso de carga en logcat desde DDMS o adb shell logcat .

Se tarda algún tiempo en cargar el emulador, pero recuerda que no es necesario reiniciarlo cuando actualizas tu código. Acaba de Run as... en eclipse y se encargará de subir y volver a instalar en el emu.

También recuerda que puedes usar tu teléfono en lugar del emulador. Usualmente uso mi teléfono cuando el PC en el que estoy trabajando es demasiado lento.

¡Buena suerte con el desarrollo de Android!

Y tal vez era sólo yo, pero me tomó un tiempo para averiguar lo que "LogCat" era que yo seguía leyendo.

Si utiliza Eclipse, haga "Ventana / Mostrar vista / Otro". A continuación, escriba "LogCat" en el cuadro "Mostrar vista" y aparecerá "Android-> LogCat". Elige esa opción y ahora tendrás una pestaña LogCat que muestra la información de salida. Puede controlar el nivel de información que se muestra con los botones "VDIWE" en la esquina superior derecha.

Después de aplicar las soluciones anteriores, intente editar su AVD, establezca la propiedad de hardware "Tamaño máximo de la aplicación VM" a 192 o superior y elija la piel QVGA. Tuve el mismo problema, y ​​con estos ajustes de la AVD cargado en menos de un minuto.

De acuerdo con el genio de arriba,

Tenía el mismo problema (pegado en la carga de "casa"), me recordó un problema de descarga que tenía (pegado al 99% y no ir más lejos -> (sí im un noob, pero todavía me recordó de eso) ) Y combinado con un odio profundamente arraigado hacia cualquier cortafuego y software de la protección del virus me proporcionaron una rabia berserker de la energía alta que destruyó todo que tenía solamente la semejanza más leve a la palabra "protección"

-> emulador funcionó bien después de eso!

• Todavía tardó 6-7 minutos para cargar el emulador, pero "logcat" puede ayudar a pasar el tiempo 🙂

Parece que la solución preferida es comprar uno de los "Teléfonos para Android" tal como se anuncian en el sitio de desarrolladores de Android.

Casi dos años después, los problemas del emulador siguen siendo los mismos. En el último Eclipse con el último plugin, después de un fallo del emulador, el uso de la CPU es del 30%, consumido por la animación bombástica en el emulador.

El complemento Eclipse tiene una vista de registro LogCat con una opción para guardar la salida en un archivo. Esta opción produce un archivo de longitud 0 con todas las entradas seleccionadas.

Esto no es software. Es otra cosa.

Para aquellos que encuentren este hilo debido a un problema más reciente, permítanme proporcionar lo siguiente. Esperemos que ahorre a la gente algunos días de pérdida de productividad y de tirar del pelo.

La última versión de Google SDK (contenido de la carpeta Herramientas) fue la versión 22.3, pero las versiones de trabajo anteriores ya no están en el archivo XML ( https://dl-ssl.google.com/android/repository/repository-8. Xml ), por lo que se quedan sin una clara ruta de degradación desde la GUI.

Este problema hace que el problema descrito por el OP para todas las versiones de la API "Intel" antes de 19 que he probado y una "excepción de punto flotante" para Intel API-19. Tenga en cuenta que las versiones Arm del emulador seguirán funcionando, aunque mucho más lentamente si se utiliza la aceleración Intel.

El problema está documentado en este subproceso, que no descubrí hasta que probé la API-19, de tal forma que el error de "coma flotante" proporcionó una coincidencia de búsqueda de google:

https://code.google.com/p/android/issues/detail?id=66786

Una solución es la implementación de Virtual Box de genymotion, aunque requiere una versión relativamente nueva de glibc, aún no estable en Debian o CentOS. (Acabo de pasar un día instalando OpenSUSE para poder "volver a trabajar" antes de encontrar la solución, arriba).

La solución más rápida es cambiar el nombre de "Tools" (dentro de la carpeta "android-sdks") a "Broken-tools", a continuación, descargar la versión anterior, que alguien en el hilo, por encima, ubicado (de alguna manera): http: // dl .google.com / android / android-sdk_r22.3-linux.tgz http://dl.google.com/android/android-sdk_r22.3-windows.zip

Al abrir el tgz, se encuentra una carpeta "Tools", que se puede copiar en la carpeta "android-sdks", donde se re-nombró la versión anterior a "Broken-Tools", arriba.

Si esos enlaces (a las versiones no alfa promocionadas como 'estables') deben morir, tenga en cuenta que existen otras copias en otras ubicaciones no oficiales (sin duda publicadas por otros desarrolladores 'frustrados' que tratan de ayudar a sus compañeros).

Gracias a Macarse, por señalarme el "adb shell logcat", que me permitió localizar el "crashing loop" que se produce en las API pre-19, creando el comportamiento "Android Splash Screen Forever", que se centra alrededor de un "SSLCertificateSocketFactory" error.