Ошибка выполнения AAPT, внезапно

Question

Я знаю, что вокруг много таких тем, но ни одна из них, похоже, не помогает в моем случае и не описывает это точно. Лучший аналогичный aapt не найден по правильному пути .

Моя проблема в том, что я могу использовать Eclipse для программирования в течение всего вечера, компилировать и использовать свое устройство, а затем внезапно я получаю «ошибку при выполнении aapt» для моего текущего проекта, и, конечно, R.java не генерируется (должным образом) больше. Затем я перезапускаю Eclipse, и все уходит. Однако в среднем я вижу это раз в день.

Я недавно переключился на amd64 и установил последнюю версию Android-2.3 SDK и соответствующие инструменты. Я знаю, что сейчас есть папка platform-tools, которая имеет версию aapt, которая должна работать независимо от версии SDK. Сначала я добавил этот каталог в свой PATH, как указано на веб-сайте SDK. Я также попытался не добавлять его к моему пути и создать ссылку платформы / android-9 / tools, чтобы каждая версия SDK могла использовать свою собственную старую копию. Само собой разумеется, платформа-инструменты / aapt есть и имеет необходимые разрешения, и я смог выполнить его в командной строке в любое время.

Когда я пишу неисправный XML-файл или сортировку и, соответственно, получаю сообщение об ошибке, я вижу дополнительную строку, которая говорит: «aapt: /lib32/libz.so.1: информация о версии недоступна». Я использую последнюю систему Gentoo Linux. У меня все установлено для поддержки x86 на amd64, но я перезапустил emul-linux-x86-baselibs и zlib, чтобы быть уверенным. Проблема сохраняется. Я вижу страниц , которые вызывают ужас над некоторыми ошибками в zlib, но я не уверен, что это связано. Я понимаю, что не на эталонной платформе Ubuntu, но, конечно, разница не может быть такой большой?

Это вполне может быть ошибка в aapt или в самом инструменте. С чего бы это вдруг перестало работать? Я также испытываю, что идентификаторы в R.java были неправильными, а именно, что простой код findViewById () мог бы дать ClassCastExceptions из-за смешанных идентификаторов один раз, а затем работать без каких-либо изменений, кроме только «чистого проекта», после неудавшаяся тревога.

Наконец, я выполнил несколько команд на aapt, которые, кажется, не добавляют никакой дополнительной информации:

#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

Кто-нибудь может сказать что-нибудь не так с моей конфигурацией? Возможно, пахнет как ошибка (в противном случае давайте сообщим (снова))?

Обновление 2010-01-06:

Я получил больше знаний. Когда я недавно пытался экспортировать подписанный apk, я столкнулся с другим сообщением об ошибке (полная информация из представления об ошибке Eclipse) относительно aapt, которого я раньше не видел. Также обратите внимание, что я могу просто перезапустить Eclipse и снова без проблем экспортировать apks, по крайней мере, на некоторое время.

Я начинаю думать, что это связано с нехваткой памяти в моей системе. Сообщение «onvoldoende geheugen beschikbaar» означает «недостаточно памяти».

Я также обнаружил недостаточные ошибки памяти в DDMS при выводе файлов HPROF.

Вот журнал ошибок (сокращенно):

!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

ошибка действительно в 32-битной libz.so.1.2.3 emul-linux !!

Я только что собрал 32-битную версию libz, и она работает - aapt не выдает вышеуказанную ошибку. если вы используете gentoo - у всех версий libz emul-linux-x86-baselibs есть эта проблема (в настоящее время 20100915-r1 и 20110129)

Вот шаги, которые вам нужны, пока не выйдет обновленная версия emul-linux-baselibs:

• получить zlib (1.2.5 в порядке)
• распаковка
• редактировать, настроить

--- 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"

• сделать
• переместить libz.so.1.2.5 в / lib32

Проблема в том, что в то время как 64-битная версия, которую вы сами компилируете, имеет следующие поля в заголовке ELF:

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

32-битная версия, предоставляемая текущей версией emul-linux-x86-baselibs, не имеет поля VERDEF, она содержит только

  [ 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

вы можете сами проверить, имеет ли ваша пользовательская сборка 32-битной библиотеки поле VERDEF - у меня есть, и мне интересно, почему оно отсутствует в дистрибутиве emul-linux ..

С уважением, cmuelle8

ps: иногда сообщения об ошибках, напечатанные компьютерными программами, являются правильными ..

Answer 2

Похоже, что реальная проблема заключается в том, что процесс aapt запрашивает неоправданное количество памяти. Памяти, которой нет в моей системе с твердотельным накопителем HD и (таким образом) без подкачки (но 4 ГБ ОЗУ), помимо уже большого процесса затмения.

Решение состоит в том, чтобы установить:

echo 1 > /proc/sys/vm/overcommit_memory

Прочтите статьи ниже, но, насколько я понимаю, ядро ​​linux имеет недостаток и несовершенно предсказывает, сколько памяти понадобится новому процессу. Этот флаг позволяет системе запускать любой процесс, в зависимости от того, сколько памяти он запрашивает. Обратите внимание, что на практике aapt никогда не будет использовать столько памяти. Кажется, что размер процесса затмения (в моем случае, например, 2 ГБ) является приблизительным, и он добавляется к любой используемой оперативной памяти (2 ГБ затмения + 0,5 ГБ другой), что превышает мою 4 ГБ оперативной памяти. Aapt будет использовать только часть 2 ГБ, но расчет не удастся.

Недостатком разрешения этого overcommit, очевидно, является то, что ядро ​​не имеет чистого решения, когда у вас мало памяти, и будет просто убивать процессы.

Другое решение состоит в том, чтобы использовать файл подкачки, в моем случае файл подкачки, поскольку я не предполагал раздел подкачки, а затем желательно с очень низкой перестановкой. В вашем руководстве по Linux должно быть указано, как это сделать, но вкратце (это только для быстрого теста, вместо этого вы должны настроить / etc / fstab):

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

echo 0 > /proc/sys/vm/swappiness

Установка своппинга на такое низкое значение делает его таким, чтобы своп в действительности никогда не использовался. Это также самый большой недостаток этого решения. На жестком диске у вас будет файл объемом 2 ГБ, который вы никогда не будете использовать, кроме как для выполнения вычислений ядра (и, возможно, из-за редкого крайне низкого уровня памяти, не знаете, как работает 0 swappiness?). Говорят, что плохая идея использовать своп на SSD, так как много записей сократит срок службы SSD.

Следующие статьи привели меня к решению.

Как решить "java.io.IOException: error = 12, Невозможно выделить память", вызывая 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

Обратите внимание, что здесь виноват не aapt, а также инструменты разработчика Android. Я мог видеть эту проблему где угодно. Однако я думаю, что из-за гигантского (и увеличивающегося) размера набора инструментов eclipse, возможно, в сочетании с некоторыми деталями реализации, такими как использование fork ()?, Эта проблема имеет очень высокую вероятность появления здесь, в том числе и для других люди с твердотельными накопителями.

Answer 3

Кстати, если вы используете Windows, может случиться так, что ваш антивирусный сканер удалит aapt.exe (именно это и сделал Avast Antivirus в моем случае)

Answer 4

Увеличьте память на studio64.vmoptions или studio.vmoptions соответственно, у меня это сработало, я просто увеличил ее, чтобы удвоить все, почти в 3 раза, например Xms 512, Xmx 4096, -XX: MaxPermSize = 720m, XX: ReservedCodeCacheSize = 128 м.

Надежда полезна для кого-то в будущем.