2012-03-22 15 views
13

He actualizado mi paquete android-sdk de r16 a r17. También actualicé el Eclipse ADT-Plugin.
Mi proyecto funcionó perfectamente bien con r16 (android-sdk r16 y Eclipse ADT Plugin v16), pero ahora la aplicación no se inicia: El cargador de clases no puede encontrar MainActivity. MainActivity es la primera actividad que se inicia (se declara correctamente en AndroidManifest).Android-SDK r17 ruinas proyectos de trabajo

 
03-22 15:07:28.984: E/AndroidRuntime(22106): Caused by: java.lang.ClassNotFoundException: my.....MainActivity 
03-22 15:07:28.984: E/AndroidRuntime(22106): at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:61) 
03-22 15:07:28.984: E/AndroidRuntime(22106): at java.lang.ClassLoader.loadClass(ClassLoader.java:501) 
03-22 15:07:28.984: E/AndroidRuntime(22106): at java.lang.ClassLoader.loadClass(ClassLoader.java:461) 
03-22 15:07:28.984: E/AndroidRuntime(22106): at android.app.Instrumentation.newActivity(Instrumentation.java:1023) 
03-22 15:07:28.984: E/AndroidRuntime(22106): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1871) 

El nombre del paquete es 100% correcto. Incluso revisé una versión etiquetada de mi proyecto (lancé el proyecto y siempre etiqueto mis versiones) y lo probé: el mismo resultado.
lo que ya he probado (yo uso Linux del arco):
- Eliminar android-sdk +-SDK-plataforma de herramientas androide (y reinstalarlos)
- borrar toda la carpeta androide (/ opt/android-sdk) y volver a instalar los paquetes, descarga la plataforma de destino
- eliminar ~/.android
- eliminar ~/.eclipse
- volver a instalar Eclipse Plugin ADT-
- volver a crear dispositivos virtuales
- crear un nuevo proyecto (la nuevo proyecto funciona)
- desempaquetar el archivo .apk- archivar y ver las clases compiladas con dexdump: el archivo apk contiene la actividad principal
- Leí el Android-SDK-Release-Notes para algo relacionado, pero no encontré nada
- Y, por supuesto, reconstruir el proyecto (limpiar + compilar, incluso borré manualmente la carpeta bin)

Lo único que realmente funcionó fue encender mi portátil (todavía android-sdk r16).
Entonces ... ¿qué estoy haciendo mal? Probablemente sea algo simple ...

¡Gracias!

+0

Pequeña adición para el paso "limpiar + compilar": el cierre y la reapertura del proyecto a veces ayudan a obligar al complemento Eclipse/ADT a regenerar todo. – Robert

Respuesta

22

Como se ha informado here y en otros lugares, debe asegurarse de que los JAR de terceros que esté utilizando vivan en libs/, tanto en su proyecto como en cualquier proyecto de biblioteca dependiente. Intenta eso y mira si ayuda.

+0

Muchas gracias. Sabía que era algo estúpido ... Google debería señalar eso en su página de inicio. Ni siquiera pensé en JAR de terceros. –

+0

Gracias por esta información. Entonces, incluso para las construcciones experimentales generales, Eclipse, solo de depuración para el emulador, cada proyecto que necesita un contenedor de terceros en particular necesita su propia copia en lugar de hacer referencia a una ubicación central. Esto parece un paso retrógrado para mí. – NickT

+0

@NickT: si está utilizando un sistema operativo que admite enlaces simbólicos, estos podrían funcionar. – CommonsWare

0

A veces además del cierre/reapertura del proyecto, el reinicio del eclipse es necesario para que todo funcione según lo previsto y esperado. Especialmente si actualizaste alguno de los componentes. Pero, por supuesto, como CommonsWare mencionó el ajuste de la carpeta de la biblioteca es obligatorio.

0

Este tema también se está discutiendo en android-developers forum. La receta mágica que funcionó para mí fue esta: además de reubicar las bibliotecas incluidas, tuve que cambiar mi SDK objetivo en Project Properties fuera de 4.0.3 y viceversa. Eso lo solucionó

4

Para aquellos desarrolladores que utilizan Ant recta construye con un build.xml a medida que ha anulado los objetivos que se refieren a "jar.libs.ref", debe tener en cuenta que este ha sido reemplazado, por lo que su construcción fallará.

El cambio de este a "project.libraries.jars" trabajado para mis objetivos, pero es probable que debe comprobar los diferenciales entre el anterior SDK/herramientas/ant/build.xml y la nueva. Siempre vale la pena tomar una copia de esto antes de actualizar las herramientas SDK, ya que las compilaciones Ant suelen romperse con el proceso de actualización.

+0

Perfecto, gracias ! – NuSkooler

0

Si no está utilizando Maven aquí está la guía detallada con imágenes, como se menciona en CommonsWare.

http://android.foxykeep.com/dev/how-to-fix-the-classdefnotfounderror-with-adt-17

Pero si está utilizando dependencias Maven no se incluyen con el M2e-androide conector proyecto de la biblioteca aún no sabe cómo manejar esto, así que si tiene proyectos de Android con Maven no actualizar a ADT 17.

Se ha lanzado la nueva versión 0.4.1 de Android Connector para M2E (m2e-android) y se corrigió un error con los proyectos de Maven. https://github.com/rgladwell/m2e-android/issues/72

0

Me tropecé con el mismo error cuando uso el ADT 18. Hubo varias causas, incluyendo tener que mover mis archivos jar de una lib a una carpeta libs. Casualmente estaba usando una nueva estación de trabajo con JDK 7 instalado. Me llevó varias horas entender que el paso de construcción dex estaba rechazando los archivos de clase compilados de uno de los archivos jar que construí por separado porque la firma de clase era inaceptable. El error informado por el paso de desarrollo dex fue "procesamiento de problemas: archivo de clase malo magic (cafebabe) o versión (0033.0000)"

Mi archivo jar consiste en código Java puro que creo usando hormiga. Para abreviar, finalmente logré que todo funcionara una vez que instalé el JDK de Java 6, agregué la ruta a la carpeta bin JDK 6 como el primer elemento en mi declaración de ruta & y luego reconstruí el archivo jar. Luego pude usar el archivo jar en mi proyecto de Android. El paso de compilación dex no rechazó las clases del archivo jar y, por lo tanto, mi aplicación se ejecutó en el dispositivo en lugar de fallar con ClassNotFoundException.

Descubrí varios consejos útiles: - Ejecutar la opción de línea de comando -v y examinar la salida con cuidado. Así es como sabía que el compilador java6 se estaba utilizando al final de todos mis cambios. Y de manera similar, cuando construí la aplicación Android usando hormiga, la etapa dex tenía suficientes detalles para decirme qué archivos jar procesó, etc.

De forma similar en Eclipse habilité el nivel detallado de registro para la salida de compilación de Android. Preferencias> Android> Compilar> Generar salida> Verbose

La salida de adb logcat en realidad informa los archivos de clase faltantes cuando carga la aplicación. Si está utilizando la vista LogCat en Eclipse, las líneas correspondientes están en texto rojo y son fáciles de detectar una vez que sabe que existen.

Espero que esto ayude a otros en una situación similar a una en la que me encontré - donde creé mis propios archivos puros java jar. Varios factores han cambiado, incluida la versión de Java SDK y las herramientas ADT, y el diagnóstico de las diversas causas fue un desafío.

Cuestiones relacionadas