erreur exécution AAPT, tout à coup
https://stackoverflow.com/questions/4567972
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je sais qu'il ya beaucoup de ces sujets autour mais ne semblent aider dans mon cas, ni décrire exactement. Le meilleur est similaire AAPT ne trouve pas sous le droit chemin .
Mon problème est que je peux être en utilisant Eclipse pour une programmation de soirée, la compilation et l'utilisation de mon appareil, et puis tout à coup, je vois « erreur exécution AAPT » pour mon projet en cours et ne sont pas R.java ofcourse (correctement) GÉNÉRÉES plus. Je puis redémarrer Eclipse et tout va. Je vois une fois par jour mais en moyenne.
J'ai récemment mis à amd64 et installé le dernier SDK Android 2.3 et les outils correspondants. Je sais qu'il ya maintenant une plate-forme d'outils dossier qui a une version AAPT qui devrait fonctionner de façon indépendante SDK version. Au début, je l'avais ajouté ce répertoire à mon chemin, comme indiqué sur le site Web du SDK. J'ai aussi essayé de ne pas l'ajouter à mon chemin et faire une des plates-formes de liaison / android-9 / outils pour que chaque version du SDK peut utiliser son propre ancienne copie. Inutile de dire que la plate-forme d'outils / AAPT est là et a les permissions, et je l'ai été en mesure d'exécuter sur la ligne de commande à tout moment.
Quand j'écris un fichier xml défectueux ou en quelque sorte, et de façon appropriée obtenir une erreur, je vois une ligne supplémentaire qui dit « AAPT: /lib32/libz.so.1: aucune information de version disponible ». Je suis en cours d'exécution d'un système Linux récent Gentoo. J'ai tout installé pour x86 sur support AMD64, mais sont réapparues Emul-linux-x86-baselibs et Zlib juste pour être sûr. Le problème persiste. Je ne vois quelques pages que l'horreur du sort sur quelques bugs zlib , mais je ne sais pas si cela est lié. Je me rends compte que je ne suis pas sur la plate-forme de référence Ubuntu, mais sûrement la différence ne peut pas être grand?
Il pourrait très bien être un bogue dans AAPT ou les outils lui-même. Pourquoi serait-il fonctionner soudainement? J'ai aussi l'expérience que les ids dans R.java étaient incorrects, à savoir que simple code findViewById () donnerait ClassCastExceptions en raison des ids mixtes le temps d'un, puis fonctionner parfaitement sans aucun changement Bü seulement un « projet propre », à la suite de un défaut aAPT.
Enfin, je l'ai exécuté quelques commandes sur AAPT, qui ne semblent pas ajouter des informations supplémentaires:
#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 mal de quoi que ce soit tell avec ma configuration? Une odeur comme un bug peut-être (sinon nous allons le signaler (nouveau))?
Mise à jour 2010-01-06:
J'ai gagné un peu plus de connaissances. Quand je récemment ai essayé d'exporter un fichier APK, je suis tombé dans un autre message d'erreur (les détails de la vue d'erreur Eclipse) en ce qui concerne AAPT je ne l'avais pas vu auparavant. Notez ici aussi, que je peux simplement redémarrer Eclipse et exporter APK à nouveau sans problème, au moins pour un moment.
Je commence à penser qu'il est lié à un manque de mémoire sur mon système. Le message "onvoldoende geheugen Beschikbaar" signifie "Mémoire insuffisante".
J'ai été voir les erreurs de mémoire insuffisante dans DDMS quand je le dumping fichiers hprof.
Voici le journal des erreurs (raccourci):
!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
La solution 2
Le problème réel semble être que le processus AAPT demande une quantité excessive de mémoire. 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é du processus d'éclipse déjà grand.
La solution consiste à définir:
echo 1 > /proc/sys/vm/overcommit_memory
Lire les articles ci-dessous, mais je crois comprendre que le noyau linux a un défaut, et est imparfaite pour prédire la quantité de mémoire un nouveau processus aura besoin. Ce drapeau permet au système de démarrer un processus, en ce qui concerne la quantité de mémoire demande. Notez que, dans la pratique AAPT ne sera jamais utiliser autant de mémoire. Il semble que la taille du processus d'éclipse (dans mon cas par exemple de 2 Go) est l'estimation et l'on ajoute à ce que la RAM est en cours d'utilisation (2 Go éclipse + 0,5 Go autre), ce qui dépasse mon 4 Go de RAM. AAPT n'utiliserait une fraction du 2 Go, mais le calcul échoue.
L'inconvénient de permettre à ce surdimensionnement est apparemment que le noyau n'a pas de solution propre lorsque vous utilisez de mémoire, et juste tuer les processus.
Une autre solution consiste à utiliser un swap, dans mon cas un fichier d'échange que je ne prévoyais pas une partition de swap, puis de préférence avec une swappiness très faible. Votre manuel linux devrait vous dire comment, mais en résumé (ce qui est seulement pour un test rapide, vous devez configurer votre / etc / fstab au lieu):
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 fait en sorte que l'échange est en réalité jamais utilisé. C'est aussi le plus gros inconvénient de cette solution. Vous aurez un fichier de 2 Go sur votre disque dur que vous ne serez jamais utiliser, sauf pour satisfaire les calculs du noyau (et peut-être une rare mémoire extrême faible, ne savez pas comment fonctionne 0 swappiness?). Il est dit d'être une mauvaise idée d'utiliser un swap sur un SSD comme les nombreuses écritures réduisent la durée de vie du SSD.
Les articles suivants me conduit à la solution.
?Notez que ce n'est pas AAPT qui est en faute, ni les outils de dev Android. Je aurais pu voir ce problème partout. Je ne pense cependant qu'en raison de la gigantesque (et de plus en plus) la taille de la boîte à outils d'éclipse, couplée peut-être avec quelques détails de mise en œuvre, telles que l'utilisation de la fourche () ?, ce problème a une très forte probabilité de surfaçage ici, aussi pour d'autres les gens avec les disques SSD.
Autres conseils
le bug est en effet dans emul-linux est 32bit libz.so.1.2.3 !!
i viens de construire une version libz 32bit moi-même et il fonctionne - AAPT ne jette pas l'erreur ci-dessus. si vous utilisez gentoo - toutes les versions libz de emul-linux-x86-baselibs ont ce problème (actuellement 20100915-r1 et 20110129)
Voici les étapes dont vous avez besoin jusqu'à ce qu'une version mise à jour de Emul-linux-baselibs est sur:
- get zlib (1.2.5 est ok)
- Déballez
- modifier 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"
- move libz.so.1.2.5 à / lib32
Le problème est que, tandis que la version 64 bits vous compiler vous-même a 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 fournie par le courant Emul-linux-x86-baselibs manque le champ VERDEF, il ne contient que
[ 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
vous pouvez vous vérifier si votre version personnalisée de 32bit lib a le champ VERDEF - Le mien et je me demande pourquoi il manque dans la distribution emul-linux ..
Cordialement, cmuelle8
ps: parfois les messages d'erreur imprimés par des programmes informatiques est droit ..
Augmenter la mémoire sur studio64.vmoptions ou studio.vmoptions en conséquence, il a travaillé pour moi, je viens augmenté à tout double, presque 3 fois par exemple Xms 512, Xmx 4096, -XX: MaxPermSize = 720m, XX: ReservedCodeCacheSize = 128m.
L'espoir est utile pour quelqu'un à l'avenir.
Par ailleurs, si vous utilisez Windows, il peut arriver que votre scanner de virus supprime les aapt.exe (c'est ce que Avast Antivirus a fait dans mon cas)
