erreur d'exécution aapt, tout d'un coup

Je sais qu'il ya beaucoup de ces sujets, mais aucun ne semble pour l'aider dans mon cas, ni le décrire exactement. La meilleure similaire est aapt pas trouvé dans le droit chemin.

Mon problème est que j'ai peut-être l'aide d'Eclipse pour une soirée de programmation, de compiler et d'utiliser mon appareil, et puis tout à coup j'ai "erreur lors de l'exécution aapt" pour mon projet actuel, et bien sûr R.java n'est pas (correctement) plus généré. J'ai ensuite redémarrer Eclipse et tout s'en va. Je le vois une fois par jour en moyenne.

J'ai récemment opté pour l'architecture amd64 et installé la dernière version Android 2.3 SDK et outils de concordance. Je sais qu'il existe maintenant une plate-forme d'outils de dossier qui a un aapt version qui devrait de travail version du SDK de façon indépendante. Au début, j'avais ajouté ce répertoire sur mon CHEMIN, comme indiqué sur le kit de développement de site web. J'ai aussi essayé de ne pas l'ajouter à mon chemin et faire un lien plates-formes/android-9/outils pour que chaque version du SDK peut utiliser ses propres ancienne copie. Inutile de dire que, platform-tools/aapt est là et a le droit d'autorisations, et j'ai été en mesure de l'exécuter sur la ligne de commande à tout moment.

Quand j'écris un mauvais fichier xml ou sortes, et de la façon appropriée d'obtenir une erreur, je vois une ligne supplémentaire qui dit "aapt: /lib32/libz..1: pas d'informations de version". Je suis en cours d'exécution d'un récent système Gentoo linux. J'ai tout installé, à l'appui de x86, amd64, mais ont ré-émergé emul-linux-x86-baselibs et zlib juste pour être sûr. Le problème persiste. Je ne vois certains pages qui sort d'horreur sur certains zlib bugs, mais je ne sais pas si c'est lié. Je me rends compte que je ne suis pas sur de la référence de la plate-forme Ubuntu, mais sûrement, la différence ne peut pas être formidable?

Il pourrait très bien être un bug dans aapt ou les outils de lui-même. Pourquoi serait-il soudainement cesser de travailler? J'ai aussi de l'expérience que l'id dans R.java était erronée, à savoir que le simple findViewById() code donnerait ClassCastExceptions en raison de mixte id la seule fois, et ensuite fonctionner parfaitement sans aucun changement bu seulement un "nettoyage de projet", à la suite de l'échec de la aapt.

Enfin, j'ai quelques commandes sur aapt, qui ne semblent pas à ajouter toute information supplémentaire:

#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

Quelqu'un peut-il dire quelque chose de mal avec ma configuration? Elle ne sent pas comme un bug peut-être (sinon, signalons - (nouveau))?

Mise à jour 2010-01-06:

J'ai acquis un peu plus de connaissances. Lorsque j'ai récemment été en essayant d'exporter signé apk, j'ai couru dans un autre message d'erreur (les détails complets de l'Éclipse erreur d'affichage) concernant aapt je n'avais pas vu avant. Notez également, que je peux juste redémarrer Eclipse et peut exporter les apk de nouveau sans problèmes, au moins pour un peu de temps.

Je commence à penser que c'est lié à un manque de mémoire sur mon système. Le message "onvoldoende geheugen beschikbaar" signifie "mémoire insuffisante".

J'ai aussi été voir des erreurs de mémoire insuffisante dans DDMS quand je suis dumping HPROF fichiers.

Voici le journal des erreurs (raccourcie):

!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

source d'informationauteur pjv

  1. 10

    le bug est en effet en emul-linux 32bit libz..1.2.3 !!

    je viens de construire un 32bit libz version de moi-même et il fonctionne - aapt ne jette pas l'erreur ci-dessus. si vous utilisez gentoo - tous libz versions de emul-linux-x86-baselibs ont ce problème (actuellement 20100915-r1 et 20110129)

    voici les étapes que vous devez jusqu'à ce qu'une version mise à jour de emul-linux-baselibs est:

    • obtenir zlib (1.2.5 est ok)
    • décompresser
    • modifier configurer
    --- configurer.vieux 2011-02-25 03:03:37.739491008 +0100 
+++ configurer 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; puis 
CFLAGS="${CFLAGS} -m64" 
SFLAGS="${SFLAGS} -m64"
    • faire
    • déplacer libz..1.2.5 /lib32

    Le Problème est que, tandis que la version 64 bits, vous compilez vous-même les champs suivants dans l'en-tête ELF:

     [ 5] .gnu.version VERSYM 00000000000017be 000017be 
[ 6] .gnu.version_d VERDEF 0000000000001890 00001890 
[ 7] .gnu.version_r VERNEED 00000000000019e8 000019e8

    la version 32 bits prévues par les emul-linux-x86-baselibs manque de VERDEF champ, il ne contient que

     [ 4] .gnu.version VERSYM 00000d9c 000d9c 0000b4 02 2 0 2 
[ 5] .gnu.version_r VERNEED 00000e50 000e50 000050 00 3 1 4

    vous pouvez vérifier vous-même si votre version personnalisée de 32 bits lib a la VERDEF champ - la mienne et je me demande pourquoi il est absent dans l'emul-distribution linux..

    ce qui concerne,
    cmuelle8

    ps: parfois, les messages d'erreur affichés par les programmes d'ordinateur est en droit..

  2. 8

    Le problème semble être que la aapt processus de demande pour un certain montant de mémoire. De mémoire que mon système avec un SSD, HD et (donc) pas de swap (mais 4 GO de RAM) n'a pas, à côté de la déjà grande éclipse du processus.

    La solution est de définir:

    echo 1 > /proc/sys/vm/overcommit_memory

    Lire les articles ci-dessous, mais ma compréhension est que le noyau linux a un défaut, et est imparfaite dans la prédiction de la quantité de mémoire, un nouveau processus a besoin. Cet indicateur permet au système de démarrer n'importe quel processus, concernant la quantité de mémoire qu'il pose. Notez que, dans la pratique, aapt sera jamais utiliser cette quantité de mémoire. Il semble que la taille de l'éclipse du processus (dans mon cas par exemple de 2 go) est l'estimation et il est ajouté à ce que la RAM est en cours d'utilisation (2 GO eclipse + 0,5 GO), ce qui dépasse mes 4 go de RAM. Aapt utiliserait seulement une fraction de 2 GO, mais le calcul échoue.

    L'inconvénient de permettre à cette surcharge, apparemment, est que le noyau n'a pas de solution propre lorsque vous êtes faible sur la mémoire, et va tout simplement tuer des processus.

    Une autre solution est d'utiliser un swap, dans mon cas, un fichier d'échange que je n'ai pas prévoir une partition de swap, et de préférence avec une très faible swappiness. Votre linux manuel devrait vous dire comment, mais en résumé (ce n'est que pour un test rapide, vous devez configurer votre /etc/fstab à la place):

    dd if=/dev/zero of=/swap bs=512 count=4M # = 2GB swapfile
mkswap /swap
swapon /swap
echo 0 > /proc/sys/vm/swappiness

    Réglage de la swappiness si bas qu'il fait en sorte que le swap est en réalité jamais utilisé. C'est également le plus gros inconvénient de cette solution. Vous aurez un fichier de 2 go sur votre disque dur que vous n'utiliserez jamais, sauf pour satisfaire le noyau de calculs (et peut-être l'un des rares extrême peu de mémoire, vous ne savez pas comment 0 swappiness œuvres?). On dit que c'est une mauvaise idée d'utiliser un swap sur un SSD comme beaucoup écrit sera de raccourcir la durée de vie du SSD.

    Les articles suivants m'a conduit à la solution.

    Comment faire pour résoudre "java.io.IOException: erreur=12, Ne peut allouer de la mémoire" appel Runtime#exec()?

    http://webcache.googleusercontent.com/search?q=cache:2NSdg-wIVsAJ:wiki.apache.org/cassandra/Operations+java.io.IOException+insufficient+system+resources+no+swap&cd=4&hl=nl&ct=clnk&gl=be&lr=lang_en|lang_nl

    Noter qu'il n'est pas aapt qui est en faute, ni la Android outils de dev. Je pouvais avoir vu ce problème n'importe où. Je ne pense cependant qu'en raison des gigantesques (et croissante) de la taille de l'éclipse toolkit, couplé avec peut-être certains détails de mise en œuvre, telles que l'utilisation de fork()?, ce problème a une très forte probabilité de surfaçage ici, aussi pour d'autres personnes avec des Ssd.

  3. 0

    Augmenter la mémoire sur les studio64.vmoptions ou en studio.vmoptions en conséquence, il a travaillé pour moi, j'ai juste augmenté à doubler tout, près de 3 fois par exemple Xms 512, Xmx 4096, -XX:MaxPermSize=720m, XX:ReservedCodeCacheSize=128m .

    Espoir est utile pour quelqu'un dans le futur.

  4. 0

    Par ailleurs, si vous utilisez Windows, il peut arriver que votre anti-virus supprime le aapt.exe (c'est ce que l'Antivirus Avast fait dans mon cas)