Distributing middleware built with the NDK raises some additional issues that
app developers do not need to worry about. Prebuilt libraries impose some of
their implementation choices on their users.

## Choosing API levels and NDK versions

Your users cannot use a [minSdkVersion](https://developer.android.com/ndk/guides/sdk-versions#minsdkversion) lower than yours. If your users' apps
need to run on API 21, you cannot build for API 24. It is okay to build your
library for a *lower* API level than your users. You can build for API
16 and remain compatible with your API 21 users.

NDK versions are largely compatible with each other, but occasionally there are
changes that break compatibility. If you know that all of your users are using
the same version of the NDK, it's best to use the same version that they do.
Otherwise, use the newest version.

## Using the STL

If you're writing C++ and using the STL, your choice between `libc++_shared` and
`libc++_static` affects your users if you distribute a shared library. If you
distribute a shared library, you must either use `libc++_shared` or ensure that
libc++'s symbols are not exposed by your library. The best way to do this is to
explicitly declare your ABI surface with a [version script](https://developer.android.com/ndk/guides/this%20also%20helps%0Akeep%20your%20implementation%20details%20private).

Another, less robust option is to use `-Wl,--exclude-libs,libc++_static.a
-Wl,--exclude-libs,libc++abi.a` when linking. This is less robust because it
will only hide the symbols in the libraries that are explicitly named, and no
diagnostics are reported for libraries that are not used (a typo in the library
name is not an error, and the burden is on the user to keep the library list up
to date). This approach also does not hide your own implementation details.

## Distributing native libraries in AARs

| **Note:** This section describes how to distribute C/C++ *APIs* to users. If your native libraries are implementation details of your *Java* API, see the [Java
| middleware with JNI libraries](https://developer.android.com/ndk/guides/middleware-vendors#java_middleware_with_jni_libraries) section.

The Android Gradle plugin can import [native dependencies](https://developer.android.com/studio/build/dependencies#using-native-dependencies) distributed in
[AARs](https://developer.android.com/studio/projects/android-library). If your users are using the Android Gradle plugin, this will be the
easiest way for them to consume your library.

Native libraries can be packaged into an AAR [by
AGP](https://developer.android.com/studio/releases/gradle-plugin#4.1-prefab-publish). This will be the
easiest option if your library is already built by [externalNativeBuild](https://developer.android.com/reference/tools/gradle-api/current/com/android/build/api/dsl/ExternalNativeBuild).

Non-AGP builds can use [ndkports](https://android.googlesource.com/platform/tools/ndkports/), or perform manual packaging by following the
[Prefab](https://google.github.io/prefab/) documentation to create the `prefab/` subdirectory of their AAR.

## Java middleware with JNI libraries

Java libraries that include JNI libraries (in other words, AARs that contain
`jniLibs`) need to be careful that the JNI libraries they include will not
collide with other libraries in the user's app. For example, if the AAR includes
`libc++_shared.so`, but a different version of `libc++_shared.so` than the app
uses, only one will be installed to the APK and that may lead to unreliable
behavior.
| **Warning:** [Bug 141758241](https://issuetracker.google.com/141758241): Older versions of the Android Gradle plugin do not currently diagnose this error condition. One of the identically named libraries will be arbitrarily chosen for packaging in the APK.

The most reliable solution is for Java libraries to include no more than **one**
JNI library (this is good advice for apps too). All dependencies including the
STL should be statically linked into the implementation library, and a version
script should be used to enforce the ABI surface. For example, a Java library
`com.example.foo` that includes the JNI library `libfooimpl.so` should use the
following version script:  

    LIBFOOIMPL {
    global:
        JNI_OnLoad;
    local:
        *;
    };

This example uses `registerNatives` via `JNI_OnLoad` as described in [JNI Tips](https://developer.android.com/training/articles/perf-jni#native-libraries)
to ensure that the minimal ABI surface is exposed and library load time is
minimized.