1Android System Image Issues 2=========================== 3 4This document contains a list of known issues in existing Android 5system images that NDK developers should be aware of. 6 7I. Android 1.5 System Issues: 8----------------------------- 9 10The following issues correspond to the official Android 1.5 11system images: 12 13 14No standard C++ library support: 15-------------------------------- 16 17The Android 1.5 system does not use any C++ standard library, and does 18not provide one to applicative native code. Instead, a very limited set 19of headers are provided (see docs/STABLE-APIS.TXT) which correspond to 20the C++ support code used to build the Android platform. 21 22It is possible to hack existing C++ STL implementations to work on top 23of this, but this is not supported yet. We recommend trying with uSTL 24and STLport at this point if you really need this. 25 26 27No support for C++ exceptions and RTTI: 28--------------------------------------- 29 30The Android 1.5 system image lacks several features necessary to reliably 31implement C++ exceptions and RTTI. C++ code that depends on these features 32will simply not link or run appropriately on Android 1.5 33 34 35C Library limitations: 36---------------------- 37 38The C library doesn't try to implement every feature under the sun. 39Most notably, pthread cancellation is not supported. A detailed overview 40of the C library and its design is available in docs/system/libc/OVERVIEW.TXT 41 42 43No SysV IPCs in C library: 44-------------------------- 45 46Unix System V Inter-Process Communication APIs (e.g. semget()) are 47intentionally not available from the C library, to avoid denial-of-service 48issues. See docs/system/libc/SYSV-IPC.TXT for details. 49 50 51C Library bug: getservbyname() returns port number in incorrect order: 52---------------------------------------------------------------------- 53 54The Android 1.5 C library function getservbyname() returns the port number 55corresponding to a given network service in incorrect order. The function 56stores its result in a 'struct servent' structure, and the port number in 57its 's_port' field. 58 59The standard mandates that this value is stored in network order (and thus 60should be converted to host order through ntohs()). However, the 1.5 61implementation is buggy and returns the number. 62 63This bug is fixed in later releases of the platform, and applications 64should not depend on the wrong behaviour in the future. Avoid using this 65function if possible; if this is not possible, try to use a small wrapper 66like the following one: 67 68static struct servent* 69my_getservbyname(const char* name, const char* proto) 70{ 71 static int has_bug = -1; 72 struct servent* ret; 73 74 if (has_bug < 0) { 75 ret = getservbyname("http",NULL); 76 has_bug = (ret == NULL || ret->s_port == 80); 77 } 78 79 ret = getservbyname(name, proto); 80 if (has_bug) 81 ret->s_port = htons(ret->s_port); 82} 83 84(the returned struct servent is thread-local and can be modified by the 85 caller. It will be over-written on the next call to the function though). 86 87 88Dynamic Linker limitations: 89--------------------------- 90 91The Android dynamic linker in 1.5 has many important limitations: 92 93- No support for LD_LIBRARY_PATH, LD_PRELOAD, RTLD_LOCAL and many 94 other options. 95 96- Static C++ constructors in executables are called twice due to a bug 97 in the C library initialization sequence. However, static C++ 98 constructors in shared libraries are only called once. 99 100- Static destructors are never called at the moment, either at program 101 exit, or when dlclose() is called. 102 103- dlerror() reporting is very limited and only provides a few generic 104 error messages that make it difficult to know why a dynamic load/link 105 operation failed. Most of the time, the culprit is a missing symbol. 106 107- A bug prevents one application shared library from depending on another 108 one. For example, if you build both libfoo.so and libbar.so for your 109 application, and list libfoo.so as a dependency for libbar.so in 110 bar/Android.mk (with LOCAL_SHARED_LIBRARIES := foo), then loading 111 libbar.so will always fail, even if you have already loaded libfoo.so 112 in your process. 113 114