error executing aapt, all of the sudden

pjv picture pjv · Dec 31, 2010 · Viewed 18.2k times · Source

I know there are a lot of these topics around but none seem to help in my case, nor describe it exactly. The best similar one is aapt not found under the right path.

My problem is that I can be using Eclipse for a whole evening programming, compiling and using my device, and then suddenly I get "error executing aapt" for my current project and ofcourse R.java isn't (properly) generated anymore. I then restart Eclipse and everything goes away. I'm seeing this once a day on average however.

I've recently switched to amd64 and installed the latest Android-2.3 SDK and matching tools. I know that there is now a platform-tools folder that has an aapt version that should work SDK version independently. At first I had added this directory to my PATH, as instructed on the SDK website. I've also tried not adding it to my path and making a link platforms/android-9/tools so that every SDK version might use it's own old copy. Needless to say, platform-tools/aapt is there and has the right permissions, and I have been able to execute it on the command-line at any time.

When I do write a faulty xml file or sorts, and appropriately get an error, I see an extra line that says "aapt: /lib32/libz.so.1: no version information available". I'm running a recent Gentoo linux system. I have everything installed to support x86 on amd64, but have re-emerged emul-linux-x86-baselibs and zlib just to be sure. The problem persists. I do see some pages that spell horror over some zlib bugs, but I'm not sure if that's related. I realize I'm not on the reference Ubuntu platform, but surely the difference cannot be that great?

It might very well be a bug in aapt or the tools itself. Why would it suddenly stop working? I also experience that the ids in R.java were incorrect, namely that simple findViewById() code would give ClassCastExceptions because of mixed ids the one time, and then work perfectly without any changes bu only a "clean project", in the aftermath of a failing aapt.

Finally, I've run a few commands on aapt, that don't seem to add any extra information:

#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

Can anybody tell anything wrong with my configuration? Does it smell like a bug perhaps (otherwise let's report it (again))?

Update 2010-01-06:

I've gained some more knowledge. When I recently was trying to export a signed apk, I ran into another error message (full details from the Eclipse error view) regarding aapt I hadn't seen before. Note here too, that I can just restart Eclipse and can export apks again without problems, at least for a little while.

I'm starting to think it is related to lack of memory on my system. The message "onvoldoende geheugen beschikbaar" means "insufficient memory available".

I have also been seeing insufficient memory errors in DDMS when I'm dumping HPROF files.

Here is the error log (shortened):

!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

Christian picture Christian · Feb 25, 2011

the bug is indeed in emul-linux's 32bit libz.so.1.2.3 !!

i just built a 32bit libz version myself and it works - aapt does not throw the above error. if you are using gentoo - all libz versions of emul-linux-x86-baselibs have this problem (currently 20100915-r1 and 20110129)

here are the steps you need until an updated version of emul-linux-baselibs is out:

  • get zlib (1.2.5 is ok)
  • unpack
  • 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
  • move libz.so.1.2.5 to /lib32

The Problem is, that while the 64bit version you compile yourself has the following fields in the ELF header:

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

the 32bit version provided by current emul-linux-x86-baselibs lacks the VERDEF field, it contains only

  [ 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

you can check yourself whether your custom build of 32bit lib has the VERDEF field - mine does and I wonder why it is missing in the emul-linux distribution..

regards, cmuelle8

ps: sometimes the error messages printed by computer programs is right..