In my current code till android 6 (API-23) i was able to open libjavacore.so
libcrypto.so and libwebviewchromium.so using dlopen() function.
but in Android N access of private library are restricted by Google. So any one can help me how to load these libraries.
Your app directly accesses private platform libraries. You should update your app to include its own copy of those libraries or use the public NDK APIs.
How to create copy of those library?
Seems like there is no way to workaround it correctly. In general you should write you own dynamic linker, that loads required libraries (or look to crazy_linker from NDK). Then you should perform symbol lookup manually. If library is already loaded by the system - you need only the latter.
Anyway such approach is fragile and doesn't guarantee that such tricks won't be disabled in the future. So better is to avoid using of private libraries and use your own versions or public NDK API instead.
Related
I'm developing a native application using C/C++.
I need to use name resolution service.
Making JNI calls is an option.
Using an external native library is another option.
However, I'm thinking about the probability of a third option.
As noted here, on devices running Android 10 and higher, this service is provided with a native library (libnetd_resolv.so).
This means, functions that I need rest in this library and I can confirm that.
My question is, can I use this library dynamically and get name resolution service?
I know that Android doesn't allow applications to use system libraries but what if I download this shared object and distribute with my application*, does it work?
If it doesn't, is there a future plan for this to work?
I'm asking because it is so weird to me that I need a function, it resides in my hands, but I have to make JNI calls in order to use it.
* When I embed the shared object in my application, there may be some compatibility problems when new updates are made to the shared object but that's not the point for me, if it works for one Android release it's ok.
Before attempting to add in a third-party library, do check if the existing Android NDK Networking APIs support your use case.
Do be aware of which versions of Android any particular API is supported.
For applications like facebook, they provide SDK . I have used many third party libraries for different requirements. What is the difference between both the cases . That is the code bundled as library or as sdk
A Library is a chunk of code that you can call from your own code, to help you do things more quickly/easily. For example, a Bitmap Processing library will provide facilities for loading and manipulating bitmap images, saving you having to write all that code for yourself.
An SDK (software development kit) is a library (often with extra tool applications, data files and sample code) that aid you in developing code that uses a particular system (e.g. extension code for using features of an operating system (Windows SDK), drawing 3D graphics via a particular system (DirectX SDK), writing add-ins to extend other applications (Office SDK), or writing code to make a device like an Arduino or a mobile phone do what you want)
From this thread
Android SDK -> is the core features and software tools that allow you to create an app for the Android Platform. An SDK contains lots of libraries and tools which you will use to develop your application.
A Library -> is a collection of pre-built compiled code which you can use to extend your application's features. For example, you may need to show some graphics in your application. Instead of creating this from scratch, you may choose to use a pre-built library someone else has developed which will give you the features you need thus saving you some time.
Thanks to Nithish for this explanations
SDK is software development kit which provides a platform/a way to develop software while library project is a project which have some lines of code to solve any desire problem, it may have design or code files.
Generally library project focus only one problem but SDK is complete kit/tool to develop any task, if want some functionality in your code which is not present in SDK than we will go for any library project.
SDK is so that you can build applications for FaceBook. SDK can usually only be used in a more specific context. A library is so that you can take the library and use it on your own applications. A library is meant to be portable.
You can obviously use code from anywhere to anywhere, but I think thats the main difference.
I find shared library(.so) in Android my device. And I want use exports functions from it. But how I understand, I need header files for this library. Where I can find it on device? What dirrectories?
Most probably the headers won't be available on the device.
As they are only needed to link against the library not for running the program normally they aren't contained in the system image on your device.
You might want to take a look into the headers that come with the NDK if the header you are looking for is contained there. (see: http://developer.android.com/tools/sdk/ndk/index.html)
If it isn't it is not part of the libraries google wants you to use as it is not considered to belong to the set of libraries google intends to keep stable.
Nevertheless you'll be able to fetch the required headers from the sources belonging to the android version running on your device in this case. (see: http://source.android.com/)
It might be possible those libraries won't be available any more after the next system upgrade then but that's especially the point about headers and libraries not included.
It's only guarenteed the libraries included in the NDK will available.
Presently in my Android system, I have developed a native library to communicate
with a connected media device over linux driver and we are accessing it from an
apk application via the Java native interface. This has been working fine till
now.
But we also have another application which needs to access the same native library
in parallel with the first application. As expected, because of the different data
section for the linked native library in the new application this approach is not
working.
To subvert this, we though of writing a new service/application which will be linked
with the native library and other applications access the APIs using binder calls to
this new service/application.
My question is:
Is this new approach feasible? Can someone help me with a better approach.
If yes, then we also need to return buffers in the API and some of the APIs are
callbacks. Can these types of functions be handled using the binder interface?
Thanks,
Ashutosh
Build an external library in a jar that provides the higher level API which in turn accesses the native library. Then use this jar library as any other lib. You may have to check how to put the .so file into the jar file to have a single library file.
I believe that the service approach is exactly how opencv achieves this.... specifically, OpenCV has a manager in thr app store. You can develop an app that implements BaseLoaderCallback, which gets the .so library from this manager. Behind the scenes, this uses a Service, ServiveConnection, and aidl to get the library... if memory serves me right.
Update...
Now that i think about it, i think OpenCV manager might just be passing the path to the library, which can then be loaded with the System.load command, which accepts the library path.
I'm working on an Android app with a Java component and a C++ component via JNI. The C++ component is used on other platforms.
It would make my life considerably easier if the C++ component could query the existing SQLite database (via the SQLite C API), without having to shell calls out to the Java side.
I know it's a long shot, has anyone attempted this?
No, the NDK only offers limited apis. The only officially supports areas are:
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
From ndk docs.
If you don't need to access the database from java, then as far as android is concerned it's just a file in a directory you have rights to. Accessing it via the platform's libsqlite.so and approved java wrappers is one way, but there is absolutely nothing stopping you from using your own sqlite implementation to operate on your own file if you really want to.
Since it's you own implementation (probably based off a copy of the current platform one), you aren't technically abusing a private api, since even if the platform's version evolves in incompatible ways you can control the evolution of your own copy.
If you wanted to optimize package size, you could first "evaluate" the platform's libsqlite.so to decide if you can work with it, and if not download your own version from your server. On my device it's only about 300K. However, this has some dependencies on other non-ndk libs as well, so a version that fully follows the nkd "rules" would probably be a bit larger as it would need to duplicate bits of some other things like libutils, etc.
The question then is if it's better for you to:
call back up through jni (the "android way")
use your own implementation (safe but a hassle to create)
abuse the existing library as long as it works, then make your own if you can't figure out how to adapt to whatever changes broke it
Try using this customized NDK with standard C++ library support http://www.crystax.net/android/ndk-r4.php