1<html><body><pre>Android 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 14C++ Runtime Support: 15-------------------- 16 17The Android C++ system runtime only provides very little support for 18C++ features (i.e. RTTI, exceptions and Standard Library). However, 19the NDK provides more advanced runtimes that can be linked into your 20application, if you need them. 21 22See docs/CPLUSPLUS-SUPPORT.html for more details. 23 24 25C Library limitations: 26---------------------- 27 28The C library doesn't try to implement every feature under the sun. 29Most notably, pthread cancellation is not supported. A detailed overview 30of the C library and its design is available in docs/system/libc/OVERVIEW.html 31 32 33No SysV IPCs in C library: 34-------------------------- 35 36Unix System V Inter-Process Communication APIs (e.g. semget()) are 37intentionally not available from the C library, to avoid denial-of-service 38issues. See docs/system/libc/SYSV-IPC.html for details. 39 40 41C Library bug: getservbyname() returns port number in incorrect order: 42---------------------------------------------------------------------- 43 44The Android 1.5 C library function getservbyname() returns the port number 45corresponding to a given network service in incorrect order. The function 46stores its result in a 'struct servent' structure, and the port number in 47its 's_port' field. 48 49The standard mandates that this value is stored in network order (and thus 50should be converted to host order through ntohs()). However, the 1.5 51implementation is buggy and returns the number. 52 53This bug is fixed in later releases of the platform, and applications 54should not depend on the wrong behaviour in the future. Avoid using this 55function if possible; if this is not possible, try to use a small wrapper 56like the following one: 57 58static struct servent* 59my_getservbyname(const char* name, const char* proto) 60{ 61 static int has_bug = -1; 62 struct servent* ret; 63 64 if (has_bug < 0) { 65 ret = getservbyname("http",NULL); 66 has_bug = (ret == NULL || ret->s_port == 80); 67 } 68 69 ret = getservbyname(name, proto); 70 if (has_bug) 71 ret->s_port = htons(ret->s_port); 72} 73 74(the returned struct servent is thread-local and can be modified by the 75 caller. It will be over-written on the next call to the function though). 76 77 78Dynamic Linker limitations: 79--------------------------- 80 81The Android dynamic linker in 1.5 has many important limitations: 82 83- No support for LD_LIBRARY_PATH, LD_PRELOAD, RTLD_LOCAL and many 84 other options. 85 86- Static C++ constructors in executables are called twice due to a bug 87 in the C library initialization sequence. However, static C++ 88 constructors in shared libraries are only called once. 89 90- Static destructors are never called at the moment, either at program 91 exit, or when dlclose() is called. 92 93- dlerror() reporting is very limited and only provides a few generic 94 error messages that make it difficult to know why a dynamic load/link 95 operation failed. Most of the time, the culprit is a missing symbol. 96 97- A bug prevents one application shared library from depending on another 98 one. For example, if you build both libfoo.so and libbar.so for your 99 application, and list libfoo.so as a dependency for libbar.so in 100 bar/Android.mk (with LOCAL_SHARED_LIBRARIES := foo), then loading 101 libbar.so will always fail, even if you have already loaded libfoo.so 102 in your process. 103 104</pre></body></html> 105