error al ejecutar aapt, de repente
https://stackoverflow.com/questions/4567972
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Sé que hay una gran cantidad de estos temas alrededor, pero ninguno parece ayudar en mi caso, ni lo describen con exactitud. La mejor similar es aapt que no se encuentran bajo el camino correcto .
Mi problema es que puedo estar usando Eclipse para una programación noche entera, la compilación y el uso del dispositivo, y de repente me sale "error al ejecutar aapt" para mi proyecto actual y por supuesto no se R.java (correctamente) generado nunca más. a continuación, reinicie Eclipse y todo desaparece. Estoy viendo esto una vez al día en promedio, sin embargo.
He cambiado recientemente para AMD64 e instalado las últimas herramientas de Android 2.3 SDK y coincidentes. Sé que hay ahora es una plataforma de herramientas de la carpeta que tiene una versión aapt que debería funcionar versión del SDK de forma independiente. Al principio yo había añadido este directorio para mi camino, como se indica en el sitio web de SDK. También he intentado no añadirla a mi camino y hacer un plataformas enlace / android-9 / herramientas para que cada versión del SDK podría utilizar su propia copia de edad. Ni que decir tiene, la plataforma de herramientas / aapt está ahí y tiene los permisos correctos, y he sido capaz de ejecutar en la línea de comandos en cualquier momento.
Cuando escribo un archivo XML defectuoso o tipo, y de manera adecuada conseguir un error, veo una línea adicional que dice "aapt: /lib32/libz.so.1: ninguna información de versión disponible". Estoy corriendo un sistema Gentoo Linux reciente. Tengo todo instalado para x86 apoyo en AMD64, pero han vuelto a aparecer Emul-linux-x86-baselibs y Zlib sólo para estar seguro. El problema persiste. Veo algunos href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431124" rel="nofollow páginas ese horror hechizo sobre algunos errores zlib , pero no estoy seguro de si que está relacionado. Me doy cuenta que no estoy en la referencia de la plataforma Ubuntu, pero seguramente la diferencia no puede ser tan grande?
Es muy bien podría ser un error en aapt o de la propia herramienta. ¿Por qué de repente dejar de trabajar? También la experiencia de que los identificadores en R.java no son correctos, es decir, que findViewById código simple () daría ClassCastExceptions a causa de las identificaciones mixtos el tiempo de uno, y luego trabajar perfectamente sin ningún cambio bu sólo un "proyecto de limpieza", como consecuencia de aapt una falla.
Por último, me he encontrado unos pocos comandos sobre aapt, que no parecen añadir cualquier información adicional:
#ldd aapt
./aapt: /lib32/libz.so.1: no version information available (required by ./aapt)
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib32/librt.so.1 (0x4f864000)
libpthread.so.0 => /lib32/libpthread.so.0 (0x4f849000)
libz.so.1 => /lib32/libz.so.1 (0xf7707000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/32/libstdc++.so.6 (0x415e9000)
libm.so.6 => /lib32/libm.so.6 (0x4f876000)
libgcc_s.so.1 => /lib32/libgcc_s.so.1 (0x4fac6000)
libc.so.6 => /lib32/libc.so.6 (0x4f5ed000)
/lib/ld-linux.so.2 (0x4f5ca000)
#file aapt
aapt: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
¿Alguien puede decir bien nada con mi configuración? ¿Huele como a un insecto tal vez (de lo contrario vamos a informar de ello (de nuevo))?
Actualización 2010-01-06:
he ganado un poco más de conocimiento. Cuando hace poco estaba tratando de exportar un archivo APK firmado, me encontré con otro mensaje de error (los detalles completos de la vista de error Eclipse) con respecto aapt que no había visto antes. Nota también en este caso, eso sólo puedo reiniciar Eclipse y puede exportar desde servidores de nuevo sin problemas, al menos por un tiempo.
Me estoy empezando a pensar que está relacionado con la falta de memoria en mi sistema. El mensaje "onvoldoende geheugen no disponible" significa "insuficiente memoria disponible".
También he estado viendo los errores de memoria insuficiente en DDMS cuando estoy vertido archivos hprof.
Aquí está el registro de errores (abreviado):
!ENTRY com.android.ide.eclipse.adt 4 0 2011-01-05 23:11:16.097
!MESSAGE Export Wizard Error
!STACK 1
org.eclipse.core.runtime.CoreException: Failed to export application
at com.android.ide.eclipse.adt.internal.project.ExportHelper.exportReleaseApk(Unknown Source)
at com.android.ide.eclipse.adt.internal.wizards.export.ExportWizard.doExport(Unknown Source)
at com.android.ide.eclipse.adt.internal.wizards.export.ExportWizard.access$0(Unknown Source)
at com.android.ide.eclipse.adt.internal.wizards.export.ExportWizard$1.run(Unknown Source)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: com.android.ide.eclipse.adt.internal.build.AaptExecException: Error executing aapt. Please check aapt is present at /opt/android-sdk/android-sdk-linux_x86-1.6_r1/platform-tools/aapt
at com.android.ide.eclipse.adt.internal.build.BuildHelper.executeAapt(Unknown Source)
at com.android.ide.eclipse.adt.internal.build.BuildHelper.packageResources(Unknown Source)
... 5 more
Caused by: java.io.IOException: Cannot run program "/opt/android-sdk/android-sdk-linux_x86-1.6_r1/platform-tools/aapt": java.io.IOException: error=12, Onvoldoende geheugen beschikbaar
...
Caused by: java.io.IOException: java.io.IOException: error=12, Onvoldoende geheugen beschikbaar
...
!SUBENTRY 1 com.android.ide.eclipse.adt 4 0 2011-01-05 23:11:16.098
!MESSAGE Failed to export application
!STACK 0
com.android.ide.eclipse.adt.internal.build.AaptExecException: Error executing aapt. Please check aapt is present at /opt/android-sdk/android-sdk-linux_x86-1.6_r1/platform-tools/aapt
at com.android.ide.eclipse.adt.internal.build.BuildHelper.executeAapt(Unknown Source)
at com.android.ide.eclipse.adt.internal.build.BuildHelper.packageResources(Unknown Source)
at com.android.ide.eclipse.adt.internal.project.ExportHelper.exportReleaseApk(Unknown Source)
at com.android.ide.eclipse.adt.internal.wizards.export.ExportWizard.doExport(Unknown Source)
at com.android.ide.eclipse.adt.internal.wizards.export.ExportWizard.access$0(Unknown Source)
at com.android.ide.eclipse.adt.internal.wizards.export.ExportWizard$1.run(Unknown Source)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: java.io.IOException: Cannot run program "/opt/android-sdk/android-sdk-linux_x86-1.6_r1/platform-tools/aapt": java.io.IOException: error=12, Onvoldoende geheugen beschikbaar
...
Caused by: java.io.IOException: java.io.IOException: error=12, Onvoldoende geheugen beschikbaar
Solución 2
El problema real parece ser que el proceso aapt está pidiendo una cantidad razonable de memoria. Recuerdo que mi sistema con un SSD de alta definición y (así) sin intercambio (pero 4 GB de RAM) no tiene, junto a la ya gran proceso de eclipse.
La solución es set:
echo 1 > /proc/sys/vm/overcommit_memory
Leer los artículos a continuación, pero mi entendimiento es que el núcleo de Linux tiene un defecto, y es imperfecta en la predicción de la cantidad de memoria necesitará un nuevo proceso. Este indicador permite que el sistema para iniciar cualquier proceso, en cuanto a la cantidad de memoria que está pidiendo. Tenga en cuenta que en la práctica nunca se aapt utilizará esta cantidad de memoria. Parece que el tamaño del proceso del eclipse (en mi caso, por ejemplo, 2 GB) es la estimación y esto se añade a lo que la RAM está en uso (2 GB Eclipse + 0.5GB otra), que supera mis 4 GB de RAM. Aapt utilizaría solamente una fracción de la de 2 GB pero falla el cálculo.
La desventaja de permitir que este overcommit parecer es que el núcleo no tiene solución limpia cuando se está ejecutando bajo en memoria, y sólo va a matar procesos.
Otra solución es utilizar un intercambio, en mi caso un archivo de intercambio, ya que no preveo una partición de intercambio y, a continuación, preferiblemente con un swappiness muy bajo. Su manual de Linux debe decirle cómo, pero en resumen (esto es sólo para una prueba rápida, debe configurar su / etc / fstab en su lugar):
dd if=/dev/zero of=/swap bs=512 count=4M # = 2GB swapfile
mkswap /swap
swapon /swap
echo 0 > /proc/sys/vm/swappiness
Configuración de la swappiness tan baja hace que sea para que el intercambio es, en realidad, nunca se utiliza. Este es también el mayor inconveniente de esta solución. Vas a tener un archivo de 2 GB en su disco duro que nunca uso, excepto para satisfacer los cálculos del kernel (y tal vez una memoria extrema baja frecuencia, no está seguro de cómo funciona swappiness 0?). Se dice que es una mala idea usar un intercambio en un SSD como las muchas escrituras acortarán la vida útil de la SSD.
Los siguientes artículos me llevaron a la solución.
?Tenga en cuenta que no es aapt que tiene la culpa aquí, ni son las herramientas dev Android. Podría haber visto esto en ningún problema. Creo sin embargo que debido a la gigantesca (y aumentar) el tamaño de la caja de herramientas Eclipse, junto quizá con algunos detalles de implementación, tales como el uso de tenedor () ?, este problema tiene una probabilidad muy alta de la superficie aquí, también para otra las personas con los SSD.
Otros consejos
el error es de hecho en emul-Linux de 32 bits libz.so.1.2.3 !!
Acabo de construir una versión de 32 bits libz mismo y funciona - aapt no lanza el error anterior. si está usando gentoo - todas las versiones de libz emul-linux-x86-baselibs tener este problema (en la actualidad 20.100.915-R1 y 20110129)
Estos son los pasos que necesita hasta que una versión actualizada de Emul-linux-baselibs está fuera:
- get zlib (1.2.5 está bien)
- unpack
- editar configure
--- configure.old 2011-02-25 03:03:37.739491008 +0100
+++ configure 2011-02-25 03:03:51.760491008 +0100
@@ -105,8 +105,8 @@
if test "$gcc" -eq 1 && ($cc -c $cflags $test.c) 2>/dev/null; then
CC="$cc"
- SFLAGS="${CFLAGS--O3} -fPIC"
- CFLAGS="${CFLAGS--O3}"
+ SFLAGS="${CFLAGS--O3} -fPIC -m32"
+ CFLAGS="${CFLAGS--O3} -m32"
if test $build64 -eq 1; then
CFLAGS="${CFLAGS} -m64"
SFLAGS="${SFLAGS} -m64"
- make
- mover a libz.so.1.2.5 / lib32
El problema es que mientras que la versión de 64 bits que compilar tu mismo tiene los siguientes campos en la cabecera ELF:
[ 5] .gnu.version VERSYM 00000000000017be 000017be [ 6] .gnu.version_d VERDEF 0000000000001890 00001890 [ 7] .gnu.version_r VERNEED 00000000000019e8 000019e8
la versión de 32 bits proporcionada por actuales Emul-linux-x86-baselibs carece del campo VERDEF, contiene exclusivamente
[ 4] .gnu.version VERSYM 00000d9c 000d9c 0000b4 02 A 2 0 2 [ 5] .gnu.version_r VERNEED 00000e50 000e50 000050 00 A 3 1 4
Puede comprobar usted mismo si su estructura de encargo de 32 bits lib tiene el campo VERDEF - el mío y me pregunto por qué no se encuentra en la distribución emul-linux ..
cordiales, cmuelle8
ps: a veces los mensajes de error impresos por programas de ordenador es correcta ..
Aumentar la memoria en studio64.vmoptions o studio.vmoptions consecuencia que trabajó para mí, me acaba de aumentar al doble todo, casi 3 veces por ejemplo Xms 512, -Xmx 4096, -XX: MaxPermSize = 720m, XX: ReservedCodeCacheSize = 128m.
La esperanza es útil para alguien en el futuro.
Por cierto, si está usando Windows puede suceder que tu antivirus elimina los aapt.exe (eso es lo que Avast Antivirus hizo en mi caso)
