Android 突然执行aapt时出错

我知道有很多这样的话题，但没有一个对我有帮助，也没有一个能准确描述。最相似的是

我的问题是，我可以使用Eclipse进行一整晚的编程、编译和使用我的设备，然后突然我得到了当前项目的“错误执行aapt”，当然R.java不再（正确地）生成。然后我重新启动Eclipse，一切都消失了。然而，我平均每天看一次

我最近切换到amd64，安装了最新的Android-2.3 SDK和配套工具。我知道现在有一个平台工具文件夹，它有一个aapt版本，该版本应该独立于SDK版本工作。起初，我已经按照SDK网站上的说明将这个目录添加到我的路径中。我也试着不将它添加到我的路径中，并创建一个链接platforms/android-9/tools，这样每个SDK版本都可以使用它自己的旧版本。不用说，platformtools/aapt已经存在，并且拥有正确的权限，我可以随时在命令行上执行它

当我确实编写了一个错误的xml文件或进行了排序，并相应地得到了一个错误时，我会看到一个额外的行，上面写着“aapt:/lib32/libz.so.1:没有可用的版本信息”。我正在运行一个最近的GentooLinux系统。我已经安装了所有支持amd64上x86的设备，但为了确保这一点，我重新推出了emul-linux-x86-baselibs和zlib。问题依然存在。我确实看到了一些关于zlib bug的令人恐惧的东西，但我不确定这是否相关。我意识到我不在参考Ubuntu平台上，但肯定区别不会那么大

这很可能是aapt或工具本身的一个bug。为什么它会突然停止工作？我还体验到R.java中的ID是不正确的，即简单的findViewById（）代码会因为混合ID一次给出ClassCastException，然后在aapt失败后，在没有任何更改的情况下完美地工作，而仅仅是一个“干净的项目”

最后，我在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时，我遇到了另一条关于aapt的错误消息（来自Eclipse错误视图的完整详细信息），这是我以前从未见过的。这里还要注意的是，我可以重新启动Eclipse，并且可以毫无问题地再次导出APK，至少在一段时间内是这样

我开始认为这与我的系统内存不足有关。消息“onvoldoende geheugen beschikbaar”表示“可用内存不足”

在转储HPROF文件时，我还看到DDMS中内存不足的错误

以下是错误日志（缩短）：

---

实际问题似乎是aapt进程要求的内存量不合理。除了已经很大的eclipse进程之外，我的带有SSD HD和（因此）无交换（但4GB RAM）的系统没有的内存

解决方案是设置：

echo 1 > /proc/sys/vm/overcommit_memory

阅读下面的文章，但我的理解是linux内核有一个缺陷，在预测一个新进程需要多少内存方面并不完美。此标志允许系统启动任何进程，与它请求的内存量有关。注意，实际上aapt永远不会使用这么多内存。似乎eclipse进程的大小（在我的例子中是2GB）是估计值，这被添加到正在使用的任何RAM中（2GB eclipse+0.5GB other），这超过了我的4GB RAM。Aapt只使用2GB的一小部分，但计算失败

允许这种过度使用的缺点显然是，当内存不足时，内核没有干净的解决方案，只会杀死进程

另一个解决方案是使用交换，在我的例子中是一个交换文件，因为我没有预见到交换分区，然后最好使用非常低的交换性。您的linux手册应该告诉您如何操作，但总而言之（这只是为了快速测试，您应该设置/etc/fstab）：

将交换设置得如此低，使得交换实际上从未使用过。这也是该解决方案的最大缺点。你的硬盘上会有一个2GB的文件，除了满足内核的计算（可能是一个罕见的极低内存，不知道0交换是如何工作的？）。据说在SSD上使用交换是一个坏主意，因为大量写入将缩短SSD的使用寿命

下面的文章让我找到了解决方案

---

注意，这里的错误不是aapt，Android开发工具也不是。我可以在任何地方看到这个问题。然而，我确实认为，由于eclipse工具包的巨大（并且不断增加）的规模，再加上一些实现细节，例如fork（）的使用，这个问题很有可能出现在这里，对于其他使用SSD的人来说也是如此。

错误确实存在于emul linux的32位libz.so.1.2.3

我自己刚刚构建了一个32位的libz版本，它可以工作-aapt不会抛出上述错误。如果您使用的是gentoo-所有版本的emul-linux-x86-baselibs都有此问题（当前为20100915-r1和20110129）

以下是更新版本的emul linux baselibs发布之前所需的步骤：

• 获取zlib（1.2.5可以）
• 打开
• 编辑配置

---configure.old 2011-02-2503:03:37.739491008+0100 +++配置2011-02-2503:03:51.760491008+0100 @@ -105,8 +105,8 @@ 如果测试“$gcc”-等式1&（$cc-c$cflags$test.c）2>/dev/null；然后 CC=“$CC” -SFLAGS=“${CFLAGS--O3}-fPIC” -CFLAGS=“${CFLAGS--O3}” +SFLAGS=“${CFLAGS--O3}-fPIC-m32” +CFLAGS=“${CFLAGS--O3}-m32” 如果测试$build64-等式1；然后 CFLAGS=“${CFLAGS}-m64” SFLAGS=“${SFLAGS}-m64”

• 制造
• 移动李

  echo 1 > /proc/sys/vm/overcommit_memory
  

  dd if=/dev/zero of=/swap bs=512 count=4M # = 2GB swapfile
  mkswap /swap
  swapon /swap
  
  echo 0 > /proc/sys/vm/swappiness
  

  --- 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" [ 5] .gnu.version VERSYM 00000000000017be 000017be [ 6] .gnu.version_d VERDEF 0000000000001890 00001890 [ 7] .gnu.version_r VERNEED 00000000000019e8 000019e8 [ 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