Home | History | Annotate | Download | only in docs 
      1 <html><body><pre>Android System Image Issues
      2 ===========================
      3 
      4 This document contains a list of known issues in existing Android
      5 system images that NDK developers should be aware of.
      6 
      7 I. Android 1.5 System Issues:
      8 -----------------------------
      9 
     10 The following issues correspond to the official Android 1.5
     11 system images:
     12 
     13 
     14 No standard C++ library support:
     15 --------------------------------
     16 
     17 The Android 1.5 system does not use any C++ standard library, and does
     18 not provide one to applicative native code. Instead, a very limited set
     19 of headers are provided (see docs/STABLE-APIS.html) which correspond to
     20 the C++ support code used to build the Android platform.
     21 
     22 It is possible to hack existing C++ STL implementations to work on top
     23 of this, but this is not supported yet. We recommend trying with uSTL
     24 and STLport at this point if you really need this.
     25 
     26 
     27 No support for C++ exceptions and RTTI:
     28 ---------------------------------------
     29 
     30 The Android 1.5 system image lacks several features necessary to reliably
     31 implement C++ exceptions and RTTI. C++ code that depends on these features
     32 will simply not link or run appropriately on Android 1.5
     33 
     34 
     35 C Library limitations:
     36 ----------------------
     37 
     38 The C library doesn't try to implement every feature under the sun.
     39 Most notably, pthread cancellation is not supported. A detailed overview
     40 of the C library and its design is available in docs/system/libc/OVERVIEW.html
     41 
     42 
     43 No SysV IPCs in C library:
     44 --------------------------
     45 
     46 Unix System V Inter-Process Communication APIs (e.g. semget()) are
     47 intentionally not available from the C library, to avoid denial-of-service
     48 issues. See docs/system/libc/SYSV-IPC.html for details.
     49 
     50 
     51 C Library bug: getservbyname() returns port number in incorrect order:
     52 ----------------------------------------------------------------------
     53 
     54 The Android 1.5 C library function getservbyname() returns the port number
     55 corresponding to a given network service in incorrect order. The function
     56 stores its result in a 'struct servent' structure, and the port number in
     57 its 's_port' field.
     58 
     59 The standard mandates that this value is stored in network order (and thus
     60 should be converted to host order through ntohs()). However, the 1.5
     61 implementation is buggy and returns the number.
     62 
     63 This bug is fixed in later releases of the platform, and applications
     64 should not depend on the wrong behaviour in the future. Avoid using this
     65 function if possible; if this is not possible, try to use a small wrapper
     66 like the following one:
     67 
     68 static struct servent*
     69 my_getservbyname(const char*  name, const char*  proto)
     70 {
     71     static int       has_bug = -1;
     72     struct servent*  ret;
     73 
     74     if (has_bug &lt; 0) {
     75         ret = getservbyname("http",NULL);
     76         has_bug = (ret == NULL || ret-&gt;s_port == 80);
     77     }
     78 
     79     ret = getservbyname(name, proto);
     80     if (has_bug)
     81         ret-&gt;s_port = htons(ret-&gt;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 
     88 Dynamic Linker limitations:
     89 ---------------------------
     90 
     91 The 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 </pre></body></html>