【翻译】(20)System Issues

-----------------

英文文档见android-ndk-r6b的documentation.html

属于Android Native Development Kit (NDK)的一部分

见

http://developer.android.com/sdk/ndk/index.html

翻译仅个人见解

-----------------

Android System Image Issues

Android系统镜像问题

===========================

This document contains a list of known issues in existing Android system images that NDK developers should be aware of.

这个文档包含NDK开发者应该意识到的，现存Android系统镜像的已知问题的列表。

I. Android 1.5 System Issues:

一、Android 1.5系统问题：

-----------------------------

The following issues correspond to the official Android 1.5 system images:

以下问题对应官方Android 1.5系统镜像：

No standard C++ library support:

缺乏对标准C++库支持：

--------------------------------

The Android 1.5 system does not use any C++ standard library, and does not provide one to applicative native code. Instead, a very limited set of headers are provided (see docs/STABLE-APIS.html) which correspond to the C++ support code used to build the Android platform.

Android 1.5系统没有使用任何C++标准库，也没有提供一种C++标准库给应用原生代码。取而代之的是提供一个非常有限的头文件集合（见docs/STABLE-APIS.html），它们对应用于构建Android平台的C++支持代码。

It is possible to hack existing C++ STL implementations to work on top of this, but this is not supported yet. We recommend trying with uSTL and STLport at this point if you really need this.

可以修改现存的C++ STL（注：C++标准模板库）实现，使其在这个平台上可用，但现在已经不支持了（注：这里可能是指，官方建议你别这样做，可能有问题）。我们强烈建议现在如果你真的需要它，尝试使用uSTL和STLport。

No support for C++ exceptions and RTTI:

缺乏对C++异常和RTTI（注：运行时类型信息，或作运行时类型标识）的支持。

---------------------------------------

The Android 1.5 system image lacks several features necessary to reliably implement C++ exceptions and RTTI. C++ code that depends on these features will simply not link or run appropriately on Android 1.5

Android 1.5系统镜像缺乏几个可靠地实现C++异常和RTTI所必需的特性。依赖于这些特性的C++代码将简单地链接或适当地运行于Android 1.5。

C Library limitations:

C库限制：

----------------------

The C library doesn't try to implement every feature under the sun. Most notably, pthread cancellation is not supported. A detailed overview of the C library and its design is available in docs/system/libc/OVERVIEW.html

C库不会尝试实现众所周知的所有特性（注：Android底层用的是C库是bionic而非glibc）。最值得留意的是，不支持pthread的线程取消（注：这里指pthread_cancel？）。C库的详细概述及其设计在docs/system/libc/OVERVIEW.html可用。

No SysV IPCs in C library:

在C库中缺乏SysV IPC（注：SysV是指系统五，早期Unix系统中与BSD并称的流派，IPC则是进程间通信的简称）：

--------------------------

Unix System V Inter-Process Communication APIs (e.g. semget()) are intentionally not available from the C library, to avoid denial-of-service issues. See docs/system/libc/SYSV-IPC.html for details.

Unix系统五进程间通信API（例如semget()）（注：获取信号量）在C库中是故意不可用的，以避免拒绝服务问题（注：简称DoS，一种通过不断地占用资源而干扰目标系统的正常运行的攻击方法，一般是指网络攻击，这里引申了）。详细请参考docs/system/libc/SYSV-IPC.html。

C Library bug: getservbyname() returns port number in incorrect order:

C库缺陷：getservbyname()以错误的顺序返回端口号：

----------------------------------------------------------------------

The Android 1.5 C library function getservbyname() returns the port number corresponding to a given network service in incorrect order. The function stores its result in a 'struct servent' structure, and the port number in its 's_port' field.

Android 1.5 C库函数getservbyname()以错误的顺序返回对应所给网络服务的端口号码。这个函数保存结果在struct servent结构体中，端口号在它的s_port域。

The standard mandates that this value is stored in network order (and thus should be converted to host order through ntohs()). However, the 1.5 implementation is buggy and returns the number.

标准要求是这个值应该按网络顺序保存（并且这样就应该能通过ntohs()函数转换为主机顺序）（注：ntohs将一个无符号短整形数从网络字节顺序转换为主机字节顺序，是network to host short的缩写）。然而1.5的实现有缺陷，返回不正确的数。

This bug is fixed in later releases of the platform, and applications should not depend on the wrong behaviour in the future. Avoid using this function if possible; if this is not possible, try to use a small wrapper like the following one:

这个bug在后来的平台发布版中修正，而应用程序不应该在未来依赖于这个错误行为。尽可能避免使用这个函数；如果可以，尝试使用小的封装，如下所示：

static struct servent*

my_getservbyname(const char*  name, const char*  proto)

{

    static int       has_bug = -1;

    struct servent*  ret;

    if (has_bug < 0) {

        ret = getservbyname("http",NULL);

        has_bug = (ret == NULL || ret->s_port == 80);

    }

    ret = getservbyname(name, proto);

    if (has_bug)

        ret->s_port = htons(ret->s_port);

}

(the returned struct servent is thread-local and can be modified by the caller. It will be over-written on the next call to the function though).

（返回的servent结构体是线程局部的，可以被调用者修改。虽然它会被下一次函数调用覆写）。

Dynamic Linker limitations:

动态链接器限制：

---------------------------

The Android dynamic linker in 1.5 has many important limitations:

1.5版的Android的动态链接器有许多重要限制：（注：Android的链接器是/system/bin/linker，而非Linux的ld）

- No support for LD_LIBRARY_PATH, LD_PRELOAD, RTLD_LOCAL and many other options.

- 不支持LD_LIBRARY_PATH、LD_PRELOAD、RTLD_LOCAL和许多其它选项。

- Static C++ constructors in executables are called twice due to a bug in the C library initialization sequence. However, static C++ constructors in shared libraries are only called once.

- 可执行文件的静态C++构造函数（注：这里应该指静态域变量的构造函数）会被调用两次，因为C库初始化顺序有缺陷。然而动态库的静态C++构造函数只会调用一次。

- Static destructors are never called at the moment, either at program exit, or when dlclose() is called.

- 静态析构函数（注：这里应该指静态域变量的析构函数），不管在程序退出还是调用dlclose()，都不会立刻执行。（注：dlclose用于关闭动态库）

- dlerror() reporting is very limited and only provides a few generic error messages that make it difficult to know why a dynamic load/link operation failed. Most of the time, the culprit is a missing symbol.

- dlerror()的报告非常有限，并且只提供很少常规的错误信息，让人难以得知动态加载或链接操作失败的原因。大部分情况下，出错原因是个缺失的符号。

- A bug prevents one application shared library from depending on another one. For example, if you build both libfoo.so and libbar.so for your application, and list libfoo.so as a dependency for libbar.so in bar/Android.mk (with LOCAL_SHARED_LIBRARIES := foo), then loading libbar.so will always fail, even if you have already loaded libfoo.so in your process.

- 有一个缺陷阻止应用程序动态库依赖于其它动态库。例如，如果你为应用程序构建libfoo.so和libbar.so，在bar/Android.mk文件中把libfoo.so列为libbar.so的依赖。（用LOCAL_SHARED_LIBRARIES := foo）那么加载libbar.so将总是失败，即便你已经在你的进程中加载了libfoo.so。