Errore di esecuzione aapt, tutto l'improvviso
https://stackoverflow.com/questions/4567972
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
So che ci sono un sacco di questi argomenti in giro ma nessuno sembra aiutare nel mio caso, non lo descrivono esattamente. Il migliore simile è aapt non trovato sotto la strada giusta .
Il mio problema è che io possa essere con Eclipse per un'intera programmazione la sera, la compilazione e usando il mio dispositivo, e poi improvvisamente mi ottenere "l'errore eseguendo aapt" per il mio progetto in corso e naturalmente R.java non è (correttamente) generata più. Ho poi riavviare Eclipse e tutto va via. Sto vedendo questo una volta al giorno, in media, tuttavia.
Recentemente ho passato a amd64 e installato i più recenti strumenti Android 2.3 SDK e di corrispondenza. So che v'è ora un platform-tools cartella che ha una versione aapt che dovrebbe funzionare la versione SDK in modo indipendente. In un primo momento avevo aggiunto questo elenco per il mio PATH, come indicato sul sito web SDK. Ho anche cercato di non aggiungere al mio percorso e facendo un piattaforme link / android-9 / strumenti in modo che ogni versione SDK potrebbe utilizzare di essa la propria vecchia copia. Inutile dire che, platform-tools / aapt c'è e ha i permessi giusti, e sono stato in grado di eseguire sulla riga di comando in qualsiasi momento.
Quando scrivo un file XML difettoso o tipi, e in modo appropriato ottengo un errore, vedo una riga aggiuntiva che dice "aapt: /lib32/libz.so.1: nessuna informazione versione disponibile". Sto correndo un recente sistema Linux Gentoo. Ho tutto installato al supporto x86 su amd64, ma sono riemersi EMUL-linux-x86-baselibs e zlib solo per essere sicuri. Il problema persiste. Vedo alcuni pagine quell'orrore incantesimo su alcuni bug zlib , ma io non sono sicuro se che è legato. Mi rendo conto che non sono sulla piattaforma di riferimento di Ubuntu, ma sicuramente la differenza non può essere quella grande?
Potrebbe benissimo essere un bug in aapt o gli strumenti stesso. Perché improvvisamente smettere di lavorare? Ho anche l'esperienza che gli ID in R.java erano errate, e cioè che semplice codice findViewById () darebbe ClassCastExceptions a causa della ids misti del tempo, e poi funziona perfettamente senza alcuna modifica bu solo un "progetto pulito", a seguito di una mancanza di AAPT.
Infine, ho incontrato un paio di comandi sul aapt, che non sembrano aggiungere qualsiasi informazione in più:
#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
Qualcuno può dire nulla di sbagliato con la mia configurazione? Ha odore come un insetto, forse (altrimenti andiamo a segnalarlo (di nuovo))?
Aggiornamento 2010-01-06:
ho acquisito qualche conoscenza in più. Quando di recente ho cercato di esportare un apk firmato, mi sono imbattuto in un altro messaggio di errore (tutti i dettagli dal punto di vista errore Eclipse) per quanto riguarda aapt che non avevo mai visto prima. Nota anche qui, che posso solo riavviare Eclipse e può esportare apks ancora una volta senza problemi, almeno per un po '.
sto iniziando a pensare che è legato alla mancanza di memoria sul mio sistema. Il messaggio "onvoldoende geheugen non disponibile" significa "memoria disponibile è insufficiente".
Ho anche stato vedere errori di memoria insufficiente in DDMS quando sto scarico file hprof.
Ecco il log degli errori (abbreviato):
!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
Soluzione 2
Il vero problema sembra essere che il processo aapt sta chiedendo per un importo irragionevole di memoria. Memoria che il mio sistema con uno SSD e HD (quindi) senza swap (ma 4GB di RAM) non ha, accanto alla già grande processo di Eclipse.
La soluzione è quella di impostare:
echo 1 > /proc/sys/vm/overcommit_memory
Leggi gli articoli qui sotto, ma la mia comprensione è che il kernel Linux ha un difetto, ed è imperfetta nel predire la quantità di memoria un nuovo processo avrà bisogno. Questo flag permette al sistema di iniziare qualsiasi processo, per quanto riguarda la quantità di memoria che sta chiedendo. Si noti che, in pratica, aapt non potrà mai utilizzare questa quantità di memoria. Sembra che la dimensione del processo di Eclipse (nel mio caso, ad esempio 2 GB) è la stima e questo si aggiunge a tutto ciò la RAM è in uso (2GB eclisse + 0.5GB altro), che supera la mia 4GB di RAM. Aapt sarebbe utilizzare solo una frazione del 2GB ma il calcolo non riesce.
Lo svantaggio di permettere questo overcommit a quanto pare è che il kernel non ha soluzione pulito quando si esegue basso sulla memoria, e sarà solo uccidere i processi.
Un'altra soluzione è quella di utilizzare uno swap, nel mio caso un file di swap come io non avevo previsto una partizione di swap, e quindi preferibilmente con un bassissimo swappiness. Il manuale linux dovrebbe dirvi come, ma in sintesi (questo è solo per un rapido test, è necessario configurare il file / etc / fstab invece):
dd if=/dev/zero of=/swap bs=512 count=4M # = 2GB swapfile
mkswap /swap
swapon /swap
echo 0 > /proc/sys/vm/swappiness
Impostazione della swappiness così basso fa sì che lo swap è, in realtà, non ha mai usato. Questo è anche il più grande svantaggio di questa soluzione. Avrai un file sul vostro hard disk da 2 GB che non verrà mai usata, tranne che per soddisfare i calcoli del kernel (e forse una rara di memoria estremamente bassa, non so come funziona 0 swappiness?). Si dice che sia una cattiva idea di utilizzare uno swap su uno SSD come i molti scrive riducono la durata della SSD.
I seguenti articoli mi hanno portato alla soluzione.
?Si noti che non è aapt che è colpa qui, e non sono gli strumenti di sviluppo di Android. Ho potuto vedere questo problema ovunque. Credo però che a causa della enorme (e crescente) dimensione del toolkit eclisse, accoppiato magari con alcuni dettagli di implementazione, come l'uso di fork () ?, questo problema ha una elevata probabilità di affioramento qui, anche per altri le persone con SSD.
Altri suggerimenti
il bug è infatti in emul-linux è 32bit libz.so.1.2.3 !!
Ho appena costruito una versione a 32 bit libz me stesso e funziona - aapt non genera l'errore precedente. se si utilizza gentoo - tutte le versioni libz di emul-linux-x86-baselibs avere questo problema (attualmente 20.100.915-r1 e 20.110.129)
qui sono i passi necessari fino a quando una versione aggiornata di EMUL-linux-baselibs è fuori:
- get zlib (1.2.5 è ok)
- disfare
- modifica 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
- mossa libz.so.1.2.5 a / lib32
Il problema è che, mentre la versione a 64 bit che si compilare autonomamente ha i seguenti campi nell'intestazione ELF:
[ 5] .gnu.version VERSYM 00000000000017be 000017be [ 6] .gnu.version_d VERDEF 0000000000001890 00001890 [ 7] .gnu.version_r VERNEED 00000000000019e8 000019e8
la versione a 32 bit fornito da correnti EMUL-linux-x86-baselibs manca il campo VERDEF, contiene solo
[ 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
è possibile controllare se la tua generazione personalizzata di 32bit lib ha il campo VERDEF - il mio lo fa e mi chiedo il motivo per cui non è presente nella distribuzione emul-linux ..
saluti, cmuelle8
ps: a volte i messaggi di errore stampati da programmi per computer è giusto ..
aumentare la memoria sulla studio64.vmoptions o studio.vmoptions di conseguenza ha funzionato per me, ho appena aumentato a doppia tutto, quasi 3 volte per esempio Xms 512, Xmx 4096, XX: MaxPermSize = 720m, XX: ReservedCodeCacheSize = 128m.
La speranza è utile per qualcuno in futuro.
A proposito, se si utilizza Windows può accadere che il vostro programma antivirus cancella le aapt.exe (questo è ciò che Avast Antivirus ha fatto nel mio caso)
