Błąd wykonywania aapt, nagle

Question

Wiem, że istnieje wiele tych tematów, ale w moim przypadku nic nie pomoże i nie opiszę ich dokładnie. Najlepszy podobny to aapt not found under the right path.

Moim problemem jest to, że mogę używać Eclipse do całonocnego programowania, kompilowania i korzystania z mojego urządzenia, a potem nagle pojawia się "błąd przy wykonywaniu aapt" dla mojego obecnego projektu i oczywiście R.java nie jest (poprawnie) generowane już. Następnie restartuję Eclipse i wszystko znika. Widzę to jednak średnio raz dziennie.

Niedawno zmieniłem system na amd64 i zainstalowałem najnowszy pakiet SDK dla systemu Android-2.3 oraz odpowiednie narzędzia. Wiem, że istnieje teraz folder narzędzi platformy, który ma wersję Aapt, która powinna działać niezależnie w wersji SDK. Na początku dodałem ten katalog do mojej PATH, zgodnie z instrukcją na stronie SDK. Próbowałem też nie dodawać go do mojej ścieżki i tworzyć platformy linków/android-9/tools, aby każda wersja SDK mogła używać swojej starej kopii. Nie trzeba dodawać, że platform-tools/aapt jest tam i ma odpowiednie uprawnienia, a ja byłem w stanie wykonać go w wierszu poleceń w dowolnym momencie.

Kiedy piszę wadliwy plik xml lub sortuję, i odpowiednio pojawia się błąd, widzę dodatkowy wiersz z napisem "aapt: /lib32/libz.so.1: brak informacji o wersji". Używam najnowszego systemu linuxowego Gentoo. Mam wszystko zainstalowane, aby obsługiwać x86 na amd64, ale ponownie pojawiły się emul-linux-x86-baselibs i zlib tylko dla pewności. Problem nadal występuje. Widzę niektóre pages, które przeliterować horror niektórych błędów ZliB, ale nie jestem pewien, czy jest to związane. Zdaję sobie sprawę, że nie jestem na popularnej platformie Ubuntu, ale z pewnością różnica nie może być tak wielka?

Może to być błąd w oprogramowaniu aapt lub w samych narzędziach. Dlaczego nagle przestałby działać? Doświadczyłem również, że identyfikatory w R.java były niepoprawne, a mianowicie, że prosty kod findViewById() dawałby ClassCastExceptions z powodu mieszanych identyfikatorów jednorazowo, a następnie działał idealnie bez żadnych zmian, ale tylko "czysty projekt", w następstwie nieudany aapt.

Wreszcie, mam uruchomić kilka poleceń na aapt, które wydają się nie dodawać żadnych dodatkowych informacji:

#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 

Czy ktoś może powiedzieć nic złego z mojej konfiguracji? Czy to może pachnieć jak robak (inaczej powiedzmy to (znowu))?

Aktualizacja 2010-01-06:

ja otrzymałem więcej wiedzy. Kiedy ostatnio próbowałem wyeksportować podpisaną apk, natknąłem się na inny komunikat o błędzie (pełne szczegóły z widoku błędu Eclipse) dotyczące wcześniejszej nieobecności. Zauważ tutaj również, że mogę po prostu ponownie uruchomić Eclipse i ponownie wyeksportować apki bez problemów, przynajmniej na chwilę.

Zaczynam myśleć, że jest to związane z brakiem pamięci w moim systemie. Komunikat "onvoldoende geheugen beschikbaar" oznacza "niewystarczającą dostępną pamięć".

Występują również niewystarczające błędy pamięci w DDMS podczas usuwania plików HPROF.

Oto dziennik błędów (skrócony):

!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 

Answer 1

Rzeczywisty problem wydaje się, że proces AAPT prosi o nadmiernych ilości pamięci. Pamięć, że mój system z SSD HD i (w ten sposób) bez wymiany (ale 4 GB pamięci RAM) nie ma, obok już dużego procesu zaćmienia.

Rozwiązaniem jest ustawienie:

echo 1 > /proc/sys/vm/overcommit_memory 

Przeczytaj poniższe artykuły, ale mój zrozumienia jest to, że jądro Linux ma wadę, a jest niedoskonała w przewidywaniu, ile pamięci nowy proces będzie potrzebne. Ta flaga zezwala systemowi na rozpoczęcie dowolnego procesu, biorąc pod uwagę ile pamięci zadaje. Zwróć uwagę, że w praktyce Aapt nigdy nie użyje tak dużej ilości pamięci. Wygląda na to, że rozmiar procesu zaćmienia (w moim przypadku na przykład 2 GB) jest szacowany i jest dodawany do jakiejkolwiek pamięci RAM w użyciu (2GB eclipse + 0.5GB inne), która przekracza moją 4 GB pamięci RAM. Aapt użyłby tylko ułamka 2GB, ale obliczenia nie powiodłyby się.

Wadą takiego zezwolenia jest to, że jądro nie ma czystego rozwiązania, gdy brakuje pamięci i po prostu zabija procesy.

Innym rozwiązaniem jest użycie wymiany, w moim przypadku pliku wymiany, ponieważ nie przewidziałem partycji wymiany, a następnie najlepiej z bardzo małą wymienialnością. Twoja instrukcja linux powinien powiedzieć, w jaki sposób, ale w podsumowaniu (to tylko dla szybkiego testu, należy skonfigurować plik/etc/fstab zamiast):

dd if=/dev/zero of=/swap bs=512 count=4M # = 2GB swapfile 
mkswap /swap 
swapon /swap 

echo 0 > /proc/sys/vm/swappiness 

Ustawianie swappiness tak niska sprawia, że ​​jest tak, że zamiana w rzeczywistości nigdy nie jest używany. To także jest największą wadą tego rozwiązania. Będziesz mieć na dysku twardym plik 2GB, którego nigdy nie użyjesz, z wyjątkiem spełnienia obliczeń jądra (i być może rzadkiej, ekstremalnie niskiej pamięci, nie wiesz, jak działa 0 swobody działania?). Mówi się, że niewłaściwym pomysłem jest używanie wymiany na SSD, ponieważ wiele zapisów skróci czas życia dysku SSD.

Poniższe artykuły doprowadziły mnie do rozwiązania.

How to solve "java.io.IOException: error=12, Cannot allocate memory" calling 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

pamiętać, że nie jest aapt że jest tu winy, ani nie są narzędzia Android Dev. Mogłem zauważyć ten problem w dowolnym miejscu. Sądzę jednak, że ze względu na gigantyczny (i rosnący) rozmiar zestawu narzędzi Eclipse, połączonego z pewnymi szczegółami implementacji, takimi jak użycie fork()?, Ten problem ma bardzo duże prawdopodobieństwo pojawienia się tutaj, także dla innych ludzie z dyskami SSD.

Answer 2

Błąd jest rzeczywiście w 32-wolnej wersji libz.so.1.2.3 emul-linux !!

Właśnie zbudowałem 32-bitową wersję libz i działa - aapt nie rzuca powyższego błędu. jeśli używasz gentoo - wszystkie wersje libz emul-linux-x86-baselibs mają ten problem (obecnie 20100915-r1 i 20110129)

tutaj są kroki, których potrzebujesz, dopóki nie skończy się zaktualizowana wersja emul-linux-baselibs :

• get zlib (1.2.5 jest ok)
• rozpakować
• edit 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
• przenieść libz.so.1.2.5 do/lib32

Problem polega na tym, że podczas gdy wersja 64bit skompilować samemu ma następujące pola w nagłówku ELF:

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

wersji 32bit dostarczonych przez obecnego emul-linux-x86- baselibs brakuje boiska VERDEF, zawiera tylko

 
    [ 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 

można sprawdzić samemu, czy zwyczaj kompilacji 32bit lib ma pole VERDEF - kopalnia robi i zastanawiam się, dlaczego go nie ma w rozkładzie emul-linux ..

pozdrowienia, cmuelle8

ps: czasami drukowane komunikaty o błędach w programach komputerowych jest prawo ..

Answer 3

zwiększyć pamięć na studio64.vmoptions lub studio.vmoptions Odpowiednio pracował dla mnie, po prostu zwiększył to podwoić wszystko, prawie 3 razy, na przykład Xms 512, Xmx 4096, -XX: MaxPermSize = 720m, XX: ReservedCodeCacheSize = 128m.

Nadzieja jest przydatna dla kogoś w przyszłości.

Answer 4

Nawiasem mówiąc, jeśli używasz systemu Windows może się zdarzyć, że skaner wirusów usuwa aapt.exe (to jest to co Avast Antivirus miało miejsce w moim przypadku)