On the topic of Swift runtimes, C++ instability, and mismatched NDK versions

[Finagolfin]

Thanks for the detailed writeup. An additional advantage of starting to "statically link the C++ runtime into thelibswiftCore.so" is that we may be able to slim the dynamic Swift runtime libraries down further through Dead-Code Elimination (DCE). I don't think limiting our SDK bundle to "only shipping [the] dynamic version of the Swift standard library" is a workable solution though, as there will undoubtedly be those who want to statically link the Swift runtime libraries, particularly for further DCE that way.

The best way to deal with all this is to document it for the user and let them decide, particularly since we currently provide no easy way to bundle all this together into an Android apk anyway.

@etcwilde

As of Android 18, the Android distribution no longer includes a full C++ runtime as part of the OS. Android applications that use C++ are expected to bundle the C++ runtime as part of the application, either as a shared library
(libc++.so) bundled in the application, or statically linked into the application binary (libc++.a).

This is not some upcoming change: it has always been the case that native code in Android apps has to include its own C++ runtime with each app, since the system doesn't provide one, unlike with Bionic libc.