Q:

Android NDK: Static or shared C++ runtime for 3rd-party Java library

I'm compiling a 3rd-party Java library for Android that uses JNI.  I read the relevant pages on adding C++ support on developer.android but I'm still confused about a couple of issues regarding C++ STL runtime that I was hoping I could clear up here:
1- My library has no control over the app it will be embedded in, so I don't know if there will be other libraries that might use a static/shared STLs.  If I use a static C++ runtime with ANDROID_STL=c++_static, is it safe, or should I have to worry about another library that could be using something like gnustl_static which might conflict with mine? 
2- If I use a shared C++ runtime with ANDROID_STL=c++_shared, is it a guarantee that a specific element in the STL will use the libc++ runtime or could it be possible to use gnustl if it doesn't exist?  For example, If I was using std::string with a shared c++ runtime (c++_shared) in an app that has another library of gnustl_static, will my std::string implementation be taken from libc++ or gnustl? 
Ideally, I'd like to have a very stripped down version of a static c++ runtime with (c++_static) that only includes std::vector, std::string and std::map.  I was actually planning to use something like -ffunction-sections as described here and #768. 
Please advise and thank you. 
Environment Details

Pkg. Desc = Android NDK 
Pkg. Revision = r15c 
Android Studio = 3.1.2
system: cmake Host OS: Arch Linux ($ uname -r % 4.18.5-arch1-1-ARCH)
Compiler: Clang++ 
STL: c++_static/c++_shared 

A:

Your concern is a very real one.  But if handled properly, you can find a robust way out. 
The warnings about using single C++ runtime across all libraries in the app (and the whole idea to define C++ support in NDK as APP_STL vs. most other flags such as LOCAL_CFLAGS or LOCAL_SHARED_LIBRARIES, are relevant for the native libraries that are connected.  JNI libraries that never communicate directly (except through their corresponding Java layers) can use different C++ runtimes.  Another point is that normal build will only package one C++ runtime shared lib into the APK.  Note that versioning is also a potential hazard: if a developer who adds your library uses a different NDK release, there might be collisions or unexpected side effects when his version of STL runtime works with your code. 
Therefore, to achieve maximum flexibility, your library should use a static C++ runtime.  This may effect the size of the binary, but if, as you say, you use only a limited subset of STL, this extra will be rather small. 
The bottom line, you will have minimum to worry about if build your shared library with libc++_static.