React native and Android 7 support with NDK restrictions - android

Native libraries must use only public API, and must not link against non-NDK platform libraries. Starting with API 24 this rule is enforced and applications are no longer able to load non-NDK platform libraries. The rule is enforced by the dynamic linker, so non-public libraries are not accessible regardless of the way code tries to load them: System.loadLibrary(...), DT_NEEDED entries, and direct calls to dlopen(...) will fail in exactly the same way.
https://android-developers.blogspot.com.by/2016/06/android-changes-for-ndk-developers.html
As I understand now React Native depends on native libraries,
any news about it?

That note refers only to non-public APIs. You still can load native libraries and still can use System.loadLibrary and dlopen as long as you are loading public APIs.

Related

Android Nougat: Detected problems with app native libraries

we just upgrade our Nexus 96 to Android N and now get the following popup while working with our app:
give me some suggestions
Check reported same issue:
https://github.com/litehelpers/Cordova-sqlcipher-adapter/issues/41
Now it has already been resolved.
For reference:
sqlcipher/android-database-sqlcipher#216
You can check SQLCipher for Android Release—Android N Support on below link:
https://discuss.zetetic.net/t/sqlcipher-for-android-release-android-n-support/1465
EDIT:
You can also check
NDK Apps Linking to Platform Libraries for private libraries usage.
Check "Update your app" section which provides steps to fix these types of errors.
You are probably using a native library that is directly accessing private APIs. The issue is described below.
From Android Developers Blog https://android-developers.googleblog.com/2016/06/android-changes-for-ndk-developers.html:
Private API (Enforced since API 24)
Native libraries must use only public API http://developer.android.com/ndk/guides/stable_apis.html?utm_campaign=android_discussion_ndkchanges_062716&utm_source=anddev&utm_medium=blog, and must not link against non-NDK platform libraries. Starting with API 24 this rule is enforced and applications are no longer able to load non-NDK platform libraries. The rule is enforced by the dynamic linker, so non-public libraries are not accessible regardless of the way code tries to load them: System.loadLibrary(...), DT_NEEDED entries, and direct calls to dlopen(...) will fail in exactly the same way.
(...)
Potential problems: starting from API 24 the dynamic linker will not load private libraries, preventing the application from loading.
Resolution: rewrite your native code to rely only on public API. As a short term workaround, platform libraries without complex dependencies (libcutils.so) can be copied to the project. As a long term solution the relevant code must be copied to the project tree. SSL/Media/JNI internal/binder APIs should not be accessed from the native code. When necessary, native code should call appropriate public Java API methods.
A complete list of public libraries is available within the NDK, under platforms/android-API/usr/lib.
As other answers pointed, it seems that this API 24 issue has been solved.

OpenSSL existing library in Android

I'm building AOSP, so lets say i have root for all module in Android. Sure there is OpenSSL library which building and reusing in other modules.
And we have base application (system, external, whatever), which also communicate with native code. And my question is: How to include in local project, existing Android OpenSSL library, to work with it?
Another say, how i can get active instance of OpenSSL/BoringSSL in native code. And also, how to get instance of Android Keystore engine and work with it?
Thanks!
From the release notes of Android 6.0:
If you’re using the Android NDK in your app, don't link against cryptographic libraries that are not a part of the NDK API, such as libcrypto.so and libssl.so. These libraries are not public APIs, and may change or break without notice across releases and devices. In addition, you may expose yourself to security vulnerabilities. Instead, modify your native code to call the Java cryptography APIs via JNI or to statically link against a cryptography library of your choice.
In your native code besides the C/native API you have access to the Java API as well. Therefore you can write C code that calls the regular Java API for accessing the AndroidKeyStore. You just have to translate the Java code into C code. Accessing the Java API this way is a bit complicated, however it is the safest way (regarding compatibility).
See also
Calling a java method from c++ in Android
Android NDK: Calling Java functions from C++

In Android, how to force the native code to use my version of a shared library, instead of the system's?

Android already has the PCRE shared library ("/system/lib/libpcre.so"), but it's compiled without Unicode support, so I've built my own version of PCRE for Android. My native code is linked to the PCRE shared library. However, when I run my app, it uses the system's version of PCRE, rather than the one I've built, even though my APK does include my version of PCRE. How do I make it use my version of PCRE rather than the system's? Generally in Linux I use "LD_LIBRARY_PATH" or "RPATH", but on Android I don't know how to use them, if that's at all possible.
You can load("your-path-to-lib") before you load the main library. With this API you can load a native library at arbitrary location. But the easiest way is to rely on the default behavior of build and installer, which will pack the native libraries (named libsomething.so) that it finds in libs/<ABI> folders, into the APK file, and unpack the ABI variant that matches the target into
getContext().getApplicationInfo().nativeLibraryDir
(this was added in API level 9)
If the library is pre-loaded, you cannot have your library side-by-side with the system one, due to a bug that invloved older versions of Android. Still, you may succeed to unload it manually, using dlclose():
handle = dlopen("<libname>", RTLD_NOLOAD);
dlclose(handle);
dlclose(handle); // twice, because dlopen() increments ref count
You will probably do these manipulations in a separate small dlclose_helper.so. Load this helper load before you load the main library, which needs the private version of <libname>.
A fix was introduced for API level 23 that lets us finally load both dir1/libx.so and dir2/libx.so (see the official doc).
Note that for API level 24, new restrictions have also been introduced that limits access to system libraries (you can only load white-listed ones).
I believe the only way is to rename the library (libpcre_myapp, for example).
Note that renaming just the file probably is not sufficient, but changing the SO_NAME ELF property.

Libraries available on Android NDK?

Are there any libraries available by default in the Android NDK? If not, can I use any c++/c library, as long as I include it myself?
In particular, I need compression, encryption, regex and sqlite. I was thinking of using zlib, crypto++, sqlite(duh!) and boost, but can use anything else if it is already available.
Also, if nothing is available built-in, would you recommend something other then my above choice (I prefer public-domain when possible, or BSD or similar)
SQLite is available on Android via abstracted database access in Java. The ‍.so itself is private. You can of course compile your own SQLite library if you require modifications, but in general you should access it from Java. I have done this for encryption purposes.
zlib is available to the NDK
crypto++ could of course be compiled via the NDK
Boost certainly works on Android/NDK (I'm currently using it heavily)
By default Android NDK delivers some libraries, so called 'stable native APIs' (http://developer.android.com/sdk/ndk/overview.html):
libc (C library) headers
libm (math library) headers
JNI interface headers
libz (Zlib compression) headers
liblog (Android logging) header
OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
libjnigraphics (Pixel buffer access) header (for Android 2.2 and above).
A Minimal set of headers for C++ support
OpenSL ES native audio libraries
Android native application APIS
First, I think you need to download the NDK package from here: http://developer.android.com/sdk/ndk/index.html and investigate the documentation from the package. I'm sure you will get the answers to most of your questions.
And quick answer to your questions. Yes there are libraries by default in the Android NDK. For example standard C and C++ libraries.
This is only a partial answer with respect to Crypto++....
Crypto++ has a wiki page with build instructions from the command line at Android (Command Line). The process will create the various libraries and show you how to build cryptest.exe to verify the library on a device. But you will still need to create you wrapper project using Android's build system.
Piotr Morgwai Kotarbiński has a page on building the Crypto++ library with Android's modified build system. See Building Crypto++ with NDK toolchain. I don't believe Piotr's article verifies the library on a device.

JNI with android?

Hey guys!
I've been working on c++ application lately which has to be run on Android 2.1 and 2.2.
so I am wondering if I have complete c++ application can I just put it into *.so file and then create android project and just simply load this library using System.loadLibrary(blalba.so);
would it work?
Yes you will have to recompile all the native libraries specifically for Android. Yes, you do need the source code for all 3rd party native libs you plan to use simply because Usually when we compile and link these libraries outside Android they are linked to glibc but unfortunately Android doesn't use glibc due to liscence and performance issues. Android uses a watered down version of glibc called libc. It has matching symbol names to glibc for most of the usual functionalities. But as far as i know the libc doesn't have some functionality related to Strings and it definitely doesnt have some posix support. If your native libraries are using any of the deprecated functionality you will have to find workaround for those by using alternative functionality supported by libc and coding your libs accordingly.
Also, as you righty pointed out you will have to use the NDK to interface Java(Android app/fwk) to native world(C++).
Though this sounds pretty simple in my experience compiling native libraries on Android(Android porting) has traditionally been very time consuming with no guarantee of sucesses.

Categories

Resources