Loading and calling native .so library using only C/C++

[Raster Ron]

Hi, is there a way to a load a native .so library and call its functions without any JNI or Java code?

[Shahriar Vaghar]

Yes. Write your code all in C or C++.

Your question is not complete.

On Wed, Jan 1, 2020, 7:54 AM Raster Ron <rast...@live.com> wrote:

Hi, is there a way to a load a native .so library and call its functions without any JNI or Java code?

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/c1231854-4744-478d-9c8b-eb7777a90dca%40googlegroups.com.

[Vano Chkheidze]

yes but you will know function names and parameters and you will load library by your self and call functions by pointer

On Wed, Jan 1, 2020, 7:54 PM Raster Ron <rast...@live.com> wrote:

Hi, is there a way to a load a native .so library and call its functions without any JNI or Java code?

--

[Raster Ron]

Thanks. I already tried to call one function as function pointer, added it in my header file, but I am still unable to load my native library and it crashes.

MyLib.c (compiled as libMyLib.so with NDK)

int add(int a, int b){
  return a + b;
}

main.c 

void (*add_ptr)(int, int) = &add;
(*add_ptr)(10,10);

Are there any steps involved to change or add in the Android.mk file particularly when going with this method?

Here's my Android.mk lib setup:

LOCAL_LDLIBS    := -L$(LOCAL_PATH)/libs/$(TARGET_ARCH_ABI) -lMyLib -llog -landroid

On Thursday, January 2, 2020 at 4:08:11 AM UTC+8, Vano Chkheidze wrote:

yes but you will know function names and parameters and you will load library by your self and call functions by pointer

On Wed, Jan 1, 2020, 7:54 PM Raster Ron <rast...@live.com> wrote:

Hi, is there a way to a load a native .so library and call its functions without any JNI or Java code?

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to andro...@googlegroups.com.

[Vano Chkheidze]

and what is crash error ? can you send what error you geting and how you are loading library ?

To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/dea7a5fc-8cb2-46a8-8f25-4ecb14a6513c%40googlegroups.com.

[Raster Ron]

The error is something like Unable to load Native Library.

as I have mentioned, I am loading the library through the Android.mk file below, my lib is named libMyLib.so

LOCAL_LDLIBS    := -L$(LOCAL_PATH)/libs/$(TARGET_ARCH_ABI) -lMyLib -llog -landroid

It does not throw undefined reference errors during ndk-build, but I am getting the said error when running the app.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/dea7a5fc-8cb2-46a8-8f25-4ecb14a6513c%40googlegroups.com.

[Vano Chkheidze]

you will use loadlibrary function without this you cant use dll without headers or efernce libs or something like that see loadlibrary function you will specify so file path you can put it in same directory where is executable or another dll and you will not need full path dll name is enough then. after this you will get acess to functions by pointers. if in project is not headers and libs then dll will not loaded automatically because linker didnot knows about your library to include it in your code so you will work with loadlibrary function to load library manual during runtime

To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/e5513b1c-efe6-464f-81c8-c980d3857bab%40googlegroups.com.

[Raster Ron]

I see. The only loadlibrary method I know is using JNI and Java with System.loadLibrary. Is there pure C/C++ way of doing this with NDK?

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/e5513b1c-efe6-464f-81c8-c980d3857bab%40googlegroups.com.

[J Decker]

On Thu, Jan 2, 2020 at 2:08 PM Raster Ron <rast...@live.com> wrote:

I see. The only loadlibrary method I know is using JNI and Java with System.loadLibrary. Is there pure C/C++ way of doing this with NDK?

Yes, libdl; dlopen, and dlsym.  Just like every other linux platform.

 

To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/a78d990a-ef4b-4fcf-b799-9ecb758c2c68%40googlegroups.com.

[Raster Ron]

Thanks! Finally, I am getting more clearer information regarding this topic, also found other related thread here: 

https://groups.google.com/forum/#!topic/android-ndk/OJxg_550eHE

I will get try this and get back in case I bump into some build or runtime issues.

cheers.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/a78d990a-ef4b-4fcf-b799-9ecb758c2c68%40googlegroups.com.

[Andrew Esh]

Here is a NDK sample that implements an activity entirely within C++ code. You should be able to do a dlopen from within such code to open your native .so library.

https://developer.android.com/ndk/samples/sample_na

[J Decker]

The only real 'gotcha' is that dlopen doesn't seem to include the app's library path;  if you have a .so you load that depends on another .so, you will likely have to load the other first (Unless it's a system library in like /usr/lib); I've heard rumors that has been fixed in recent NDK's; I'm going back to 9 or 10... and maybe it depends on other factors. 

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/5d2afabf-0a39-41f1-a469-534a61736434%40googlegroups.com.

[Andrew Esh]

See my post about the native library path: https://groups.google.com/d/msg/android-ndk/1sTM91TRjaM/nOpH-kkaBgAJ

The problem is: This would require a call from the C++ code through the JNI to get the path. Perhaps there is a way to make that call directly from C++.

On Friday, January 3, 2020 at 10:45:56 PM UTC-6, J Decker wrote:

The only real 'gotcha' is that dlopen doesn't seem to include the app's library path;  if you have a .so you load that depends on another .so, you will likely have to load the other first (Unless it's a system library in like /usr/lib); I've heard rumors that has been fixed in recent NDK's; I'm going back to 9 or 10... and maybe it depends on other factors. 

On Fri, Jan 3, 2020 at 5:19 PM Andrew Esh <andre...@gmail.com> wrote:

Here is a NDK sample that implements an activity entirely within C++ code. You should be able to do a dlopen from within such code to open your native .so library.

https://developer.android.com/ndk/samples/sample_na

On Wednesday, January 1, 2020 at 9:54:37 AM UTC-6, Raster Ron wrote:

Hi, is there a way to a load a native .so library and call its functions without any JNI or Java code?

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to andro...@googlegroups.com.

[Alex Cohn]

Android application starts its life in JVM. But you don't need to write a single line of Java code: NDK comes with NativeActivity framework. You can develop a pure native app in Android Studio or with Microsoft Visual Studio (https://docs.microsoft.com/en-us/visualstudio/cross-platform/create-an-android-native-activity-app).

Another approach to running pure C++ code on Android involves changing the platform. Under the hood, Android is almost yet another Linux, and it runs Linux-style services. See e.g. https://devarea.com/aosp-adding-a-native-daemon.

BR,

Alex Cohn

[Raster Ron]

Thanks guys!

I can already do Native C++ just with the main file similar to the sample_na from the online android docs.

I am still looking for an example perhaps like a Hello World template on how to load a .so file using only pure C/C++ without JNI/Java. I was hoping this has been covered already, but still cannot find any plain and simple example on how its done, also not involving any root access or related method.

[Shahriar Vaghar]

http://man7.org/linux/man-pages/man3/dlopen.3.html

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/7353585d-adcc-4c8b-a119-4c6317e44e1a%40googlegroups.com.

[J Decker]

On Tue, Jan 14, 2020 at 2:07 PM Raster Ron <rast...@live.com> wrote:

Really?  What happens when you just use dlopen?  Does it not find it because the library path isn't part of the path?  (could be, I forget....)

I find 'myself', that being the library that is currently running with...

I read /proc/self/maps and find the memory region containing the current running routine.

https://github.com/d3x0r/SACK/blob/master/src/systemlib/system.c#L513-L560

https://github.com/d3x0r/SACK/blob/master/src/deadstart/android/default_android_main.c#L577-L643  (this one probably)

That gives you the full path to the current library, from which you can strip the library name and get the path... then you can use that path to prepend to other libraries you've packaged with your app.

I've been told 'DO NOT DO THIS', many times; they claim that there's some magic like the dll's aren't actually installed out of the APK so you can't get it from just the disk... but, if it works, what's the big deal?

I also extract all my data assets manually, so i can just use standard file operations for my images, etc...

(ExportAssets)

https://github.com/d3x0r/SACK/blob/master/src/deadstart/android/default_android_main.c#L504-L527

 

Which, all together, read /proc/self/maps, ExportAssets, and then start using dlopen/dlsym to load the libraries.

https://github.com/d3x0r/SACK/blob/master/src/deadstart/android/default_android_main.c#L654-L804

[J Decker]

On Tue, Jan 14, 2020 at 7:21 PM J Decker <d3c...@gmail.com> wrote:

On Tue, Jan 14, 2020 at 2:07 PM Raster Ron <rast...@live.com> wrote:

Thanks guys!

I can already do Native C++ just with the main file similar to the sample_na from the online android docs.

I am still looking for an example perhaps like a Hello World template on how to load a .so file using only pure C/C++ without JNI/Java. I was hoping this has been covered already, but still cannot find any plain and simple example on how its done, also not involving any root access or related method.

Really?  What happens when you just use dlopen?  Does it not find it because the library path isn't part of the path?  (could be, I forget....)

I find 'myself', that being the library that is currently running with...

I read /proc/self/maps and find the memory region containing the current running routine.

https://github.com/d3x0r/SACK/blob/master/src/systemlib/system.c#L513-L560

https://github.com/d3x0r/SACK/blob/master/src/deadstart/android/default_android_main.c#L577-L643  (this one probably)

That gives you the full path to the current library, from which you can strip the library name and get the path... then you can use that path to prepend to other libraries you've packaged with your app.

I've been told 'DO NOT DO THIS', many times; they claim that there's some magic like the dll's aren't actually installed out of the APK so you can't get it from just the disk... but, if it works, what's the big deal?

I also extract all my data assets manually, so i can just use standard file operations for my images, etc...

(ExportAssets)

https://github.com/d3x0r/SACK/blob/master/src/deadstart/android/default_android_main.c#L504-L527

 

Which, all together, read /proc/self/maps, ExportAssets, and then start using dlopen/dlsym to load the libraries.

https://github.com/d3x0r/SACK/blob/master/src/deadstart/android/default_android_main.c#L654-L804

snprintf( buf, 256, "%s.code.so", myname );

(I was thinking that maybe Id idn't have to do that, there's another place that just does dlopen('bag.externals.so" ).. but I guess id o...

One minor thing If your .so depends on other .so's you will have to manually load them first.

Updating LD_LIBRARY_PATH does not help after the program has begun to run.

If a library fails to load, you get back an error message about the failed dependancy; you can parse that to get the other library, and just auto load it; but when you reload the first one, you still get the exact same error, as if dlopen keeps a cached status of attempted loads.

[J Decker]

On Tue, Jan 14, 2020 at 7:30 PM J Decker <d3c...@gmail.com> wrote:

On Tue, Jan 14, 2020 at 7:21 PM J Decker <d3c...@gmail.com> wrote:

On Tue, Jan 14, 2020 at 2:07 PM Raster Ron <rast...@live.com> wrote:

Thanks guys!

I can already do Native C++ just with the main file similar to the sample_na from the online android docs.

I am still looking for an example perhaps like a Hello World template on how to load a .so file using only pure C/C++ without JNI/Java. I was hoping this has been covered already, but still cannot find any plain and simple example on how its done, also not involving any root access or related method.

Really?  What happens when you just use dlopen?  Does it not find it because the library path isn't part of the path?  (could be, I forget....)

I find 'myself', that being the library that is currently running with...

I read /proc/self/maps and find the memory region containing the current running routine.

https://github.com/d3x0r/SACK/blob/master/src/systemlib/system.c#L513-L560

https://github.com/d3x0r/SACK/blob/master/src/deadstart/android/default_android_main.c#L577-L643  (this one probably)

That gives you the full path to the current library, from which you can strip the library name and get the path... then you can use that path to prepend to other libraries you've packaged with your app.

I've been told 'DO NOT DO THIS', many times; they claim that there's some magic like the dll's aren't actually installed out of the APK so you can't get it from just the disk... but, if it works, what's the big deal?

I also extract all my data assets manually, so i can just use standard file operations for my images, etc...

(ExportAssets)

https://github.com/d3x0r/SACK/blob/master/src/deadstart/android/default_android_main.c#L504-L527

 

Which, all together, read /proc/self/maps, ExportAssets, and then start using dlopen/dlsym to load the libraries.

https://github.com/d3x0r/SACK/blob/master/src/deadstart/android/default_android_main.c#L654-L804

snprintf( buf, 256, "%s.code.so", myname );

Oh, ignore that; I use a function 'LoadLibrary' which is a wrapper around dlopen which tries several paths... so internally, I'm sure, now, that the path is used after being set to load the library from the right place. 

[Dan Albert]

I've been told 'DO NOT DO THIS', many times; they claim that there's some magic like the dll's aren't actually installed out of the APK so you can't get it from just the disk... but, if it works, what's the big deal?

You're wasting the user's disk space. It only works because your APK is still built with android:extractNativeLibs set to true (the default until targetSdkVersion 29).

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAA2GJqWOLi3BA_vnHcSgyB9wPQ%3DiBd9_5-g0WVVYoP3fMfrFVA%40mail.gmail.com.

[J Decker]

On Wed, Jan 15, 2020 at 1:29 PM 'Dan Albert' via android-ndk <andro...@googlegroups.com> wrote:

I've been told 'DO NOT DO THIS', many times; they claim that there's some magic like the dll's aren't actually installed out of the APK so you can't get it from just the disk... but, if it works, what's the big deal?

You're wasting the user's disk space. It only works because your APK is still built with android:extractNativeLibs set to true (the default until targetSdkVersion 29).

well; in that particular case, that's nothing to do with the asset extraction, but merely running my libraries, which, had apparently in every version to 21 or 24 always been extracted for me... so that's no reason.

glad to know that I still can by setting a new option though :)

yea, i'll waste 3-4 megs.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAFVaGhtxYNt7xQu5V-wfErfiO2HuxNB7a%3DiAUgSiY0WTnJm90w%40mail.gmail.com.

[J Decker]

[J Decker]

Shoot, sorry about that empty reply... I really should wait a second before sending these.

If Android really wanted to not waste space (or for me to) they should just mount my APK in a FUSE mount and allow simple file access without extracting assets... and dlopen would still find it was in a path with other libraries of the correct ABI compilation format in that same path.

[Dan Albert]

If Android really wanted to not waste space (or for me to) they should just mount my APK in a FUSE mount and allow simple file access without extracting assets... and dlopen would still find it was in a path with other libraries of the correct ABI compilation format in that same path.

Yeah, I've asked for this too: https://github.com/android/ndk/issues/1061. Not really an NDK bug, of course. 

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAA2GJqVKafZAnJmx7TyFySP9dM_%2BfDZ3SO45LVuUUz9s9nUNzw%40mail.gmail.com.

[Raster Ron]

Thanks guy for all the feedback. After some thought and testing, I have managed and just use JNI as it seems it is the easier way to go and will have more use of it eventually like 3rd party and other integration.