Fehler beim Ausführen von AAPT plötzlich
https://stackoverflow.com/questions/4567972
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich weiß, dass es viele dieser Themen gibt, aber in meinem Fall scheint es keine zu helfen, noch beschreiben Sie es genau. Das beste ähnliche ist aapt nicht unter dem richtigen Weg gefunden.
Mein Problem ist, dass ich Eclipse für ein ganzes Abendprogrammierung, das Zusammenstellen und die Verwendung meines Geräts verwenden kann. Plötzlich erhalte ich plötzlich "Fehler, aAPT" für mein aktuelles Projekt und natürlich wird R.Java nicht mehr (richtig) generiert. Ich starte dann Sonnenfinsternis neu und alles verschwindet. Ich sehe das jedoch im Durchschnitt einmal am Tag.
Ich habe kürzlich zu AMD64 gewechselt und die neuesten Android-2.3 SDK- und Matching-Tools installiert. Ich weiß, dass es jetzt einen Plattform-Tools-Ordner gibt, der eine AAPT-Version hat, die eine SDK-Version unabhängig bearbeiten sollte. Zuerst hatte ich dieses Verzeichnis meinem Weg hinzugefügt, wie auf der SDK -Website angewiesen. Ich habe auch versucht, es nicht auf meinen Pfad hinzuzufügen und eine Link-Plattformen/Android-9/Tools zu erstellen, damit jede SDK-Version ihre eigene alte Kopie verwendet. Unnötig zu erwähnen, dass Plattform-Tools/AAPT da sind und die richtigen Berechtigungen haben, und ich konnte sie jederzeit auf der Befehlszeile ausführen.
Wenn ich eine fehlerhafte XML -Datei oder eine fehlerhafte XML -Datei schreibe und einen Fehler angemessen errege, sehe ich eine zusätzliche Zeile mit der Aufschrift "aapt: /lib32/libz.so.1: Keine Versionsinformationen verfügbar". Ich führe ein kürzlich durchgeführter Gentoo Linux -System aus. Ich habe alles installiert, um X86 auf AMD64 zu unterstützen, aber Emul-Linux-X86-Baselibs und ZLIB wieder aufgenommen, um sicher zu sein. Das Problem besteht weiterhin. Ich sehe einige Seiten Dieser Zauber von Horror über einige Zlib -Fehler, aber ich bin mir nicht sicher, ob das zusammenhängt. Mir ist klar, dass ich nicht auf der Referenz -Ubuntu -Plattform bin, aber der Unterschied kann sicherlich nicht so gut sein?
Es könnte sehr gut ein Fehler in AAPT oder den Werkzeugen selbst sein. Warum sollte es plötzlich aufhören zu arbeiten? Ich erlebe auch, dass die IDs in R.Java falsch waren, nämlich, dass einfacher FindViewById () -Code ClassCastExceptions aufgrund gemischter IDs einmal zu geben und dann perfekt funktioniert, ohne dass sich nur ein "sauberes Projekt" nach der Folge von einem "sauberen Projekt" bezeichnet eine fehlgeschlagene AAPT.
Schließlich habe ich ein paar Befehle auf AAPT ausgeführt, die keine zusätzlichen Informationen hinzufügen:
#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
Kann jemand etwas falsch mit meiner Konfiguration erzählen? Riecht es vielleicht nach einem Fehler (sonst melden wir ihn (wieder))?
Update 2010-01-06:
Ich habe mehr Wissen gewonnen. Als ich kürzlich versuchte, eine signierte APK zu exportieren, habe ich eine weitere Fehlermeldung (vollständige Details aus der Eclipse -Fehleransicht) in Bezug auf AAPT getroffen, die ich zuvor noch nicht gesehen hatte. Beachten Sie auch hier, dass ich Eclipse einfach neu starten und APKs ohne Probleme wieder exportieren kann, zumindest für eine Weile.
Ich fange an zu denken, dass es mit dem Mangel an Gedächtnis in meinem System zusammenhängt. Die Meldung "Onvoldoende Geheugen Becikbaar" bedeutet "unzureichendem Speicher".
Ich habe auch unzureichende Speicherfehler in DDMS gesehen, wenn ich HPROF -Dateien abgelegen habe.
Hier ist das Fehlerprotokoll (verkürzt):
!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
Lösung 2
Das tatsächliche Problem scheint zu sein, dass der AAPT -Prozess eine unangemessene Menge an Speicher verlangt. Speicher, das mein System mit einem SSD -HD und (also) kein Swap (aber 4 GB RAM) nicht neben dem bereits großen Sonnenfinsternisprozess hat.
Die Lösung besteht darin, festzustellen:
echo 1 > /proc/sys/vm/overcommit_memory
Lesen Sie die folgenden Artikel, aber mein Verständnis ist, dass der Linux -Kernel einen Fehler hat und unvollkommen ist, wie viel Gedächtnis ein neuer Prozess benötigt wird. Dieses Flag ermöglicht es dem System, jeden Prozess zu starten, in Bezug auf die Frage, wie viel Speicher es fragt. Beachten Sie, dass AAPT in der Praxis niemals so viel Speicher verwenden wird. Es scheint, dass die Größe des Eclipse -Prozesses (in meinem Fall beispielsweise 2 GB) die Schätzung ist und dies zu einem beliebigen RAM hinzugefügt wird (2 GB Eclipse + 0,5 GB andere), was meinen 4 GB RAM überschreitet. AAPT würde nur einen Bruchteil der 2 GB verwenden, aber die Berechnung fällt fehl.
Der Nachteil, dass dieser Überbeamte offenbar ist, dass der Kernel keine saubere Lösung hat, wenn Sie den Speicher nur wenig ausführen und nur Prozesse abtöten.
Eine andere Lösung besteht darin, einen Swap zu verwenden, in meinem Fall eine Swap -Datei, da ich keine Tauschpartition vorhersehte und dann vorzugsweise mit einem sehr niedrigen Swappiness. Ihr Linux -Handbuch sollte Ihnen mitteilen, wie, aber zusammenfassend (dies gilt nur für einen kurzen Test, Sie sollten stattdessen Ihre /etc /fstab einrichten):
dd if=/dev/zero of=/swap bs=512 count=4M # = 2GB swapfile
mkswap /swap
swapon /swap
echo 0 > /proc/sys/vm/swappiness
Das Setzen des Swappens so niedrig macht es so, dass der Tausch in Wirklichkeit nie verwendet wird. Dies ist auch der größte Nachteil dieser Lösung. Sie haben eine 2 -GB -Datei auf Ihrem Harddisk, die Sie nie verwenden werden, außer um die Berechnungen des Kernels zu erfüllen (und vielleicht einen seltenen extremen Speicher, nicht sicher, wie 0 Swappiness funktioniert?). Es soll eine schlechte Idee sein, einen Tausch gegen eine SSD zu verwenden, da die vielen Schreibungen die Lebensdauer der SSD verkürzen.
Die folgenden Artikel führten mich zur Lösung.
Wie löste ich "java.io.ioException: error = 12, kann Speicher nicht zuweisen" Runime#exec ()?
Beachten Sie, dass es hier weder AAPT schuld ist, noch die Android -Entwicklerwerkzeuge. Ich hätte dieses Problem überall sehen können. Ich denke jedoch Menschen mit SSDs.
Andere Tipps
Der Fehler ist in der Tat in Emul-Linuxs 32-Bit-Libz.so.1.2.3 !!
Ich habe gerade selbst eine 32 -Bit -Libz -Version gebaut und es funktioniert - Aapt wirft den obigen Fehler nicht. Wenn Sie Gentoo verwenden-haben alle Libz-Versionen von Emul-Linux-X86-Baselibs dieses Problem (derzeit 20100915-R1 und 20110129)
Hier sind die Schritte, die Sie benötigen, bis eine aktualisierte Version von Emul-Linux-Baselibs veröffentlicht wird:
- Holen Sie sich ZLIB (1.2.5 ist in Ordnung)
- auspacken
- Konfigurieren bearbeiten
--- 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"
- machen
- Bewegen Sie libz.so.1.2.5 nach /lib32
Das Problem ist, dass die 64 -Bit -Version, die Sie selbst zusammenstellen, die folgenden Felder im ELF -Header enthält:
[ 5] .gnu.version VERSYM 00000000000017be 000017be [ 6] .gnu.version_d VERDEF 0000000000001890 00001890 [ 7] .gnu.version_r VERNEED 00000000000019e8 000019e8
Die 32-Bit-Version, die von aktuellen Emul-Linux-X86-Baselibs bereitgestellt wird
[ 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
Sie können sich selbst überprüfen, ob Ihr benutzerdefinierter Build von 32bit Lib das Verdef -Feld hat - meins und ich frage mich, warum es in der Emul -Linux -Verteilung fehlt.
Grüße, Cmuelle8
PS: Manchmal sind die von Computerprogrammen gedruckten Fehlermeldungen richtig.
Erhöhen Sie den Speicher auf Studio64.vMoptions oder Studio.
Hoffnung ist in Zukunft für jemanden nützlich.
Übrigens, wenn Sie Windows verwenden, kann es passieren, dass Ihr Virus -Scanner die aapt.exe löscht (das hat das Avast -Antivirus in meinem Fall getan)
