Fixes: dotnet#4983 Context: https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#FLAG_EXTRACT_NATIVE_LIBS Xamarin.Android has supported the [extractNativeLibs][0] attribute (introduced by Android API 23) on the `<application>` element in AndroidManifest.xml since 95ca102, with a single significant modification in feb9ea2 after we discovered that Android build system can set the flag when constructing the APK after we are done packaging. feb9ea2 introduced a runtime check to see whether the `FLAG_EXTRACT_NATIVE_LIBS` is *not* set, which meant that the native libraries are to stay in the APK file and we need to set up our DSO search paths to point to the inside of APK files instead of the traditional filesystem location. However, it appears that Android 10 (API 29, on both devices and in emulators) and Android 9 (API 28, on *just* the devices) broke the `FLAG_EXTRACT_NATIVE_LIBS` semantics in that it is possible for the flag to be *set* (which means libraries are *extracted*) with the libraries not extracted from APKs, thus breaking the logic implemented in feb9ea2. It is possible that other Android versions are affected as well, which means we can no longer trust the flag value and need to implement another way of checking whether the libraries are on the filesystem or in the APK. The simplest approach is to check for existence of a known library in the filesystem location, regardless of the API level, and assume the flag is *not* set if the shared library is missing. This is what this commit implements. The check is performed once on application startup, thus minimizing the performance impact. [0]: https://developer.android.com/guide/topics/manifest/application-element#extractNativeLibs Co-Authored by: Jonathan Peppers (@jonathanpeppers)

Commits

Commits on Aug 10, 2020

Work around Android 9+ bug with extractNativeLibs flag