I have a lib and dll files (I can choose which file I want to use)
I want to call to functions that are inside the file.
The code that complied in dll/lib wrote at c
dll files (unless the dll is a dot.net dll and you are in a Xamarin app) are not usable in Android.
Furthermore DLL files typically are compiled for x86 (32bit) or x86_64 (64bit) CPUs. The number of Andorid devices with an x86 CPU is next to zero, for Android you need the library compiled for ARMv7 (32bit) and ARMv8 (64bit). As Android is Linux based you need .so files in stead of .dll files.
To make development easier you should install Android Studio + Android NDK (Native Development Kit). Then you have everything for compiling c code in a way that you can make use of it within an Android app.
Google provides multiple sample projects that show how to use NDK: https://developer.android.com/ndk/samples
Related
I am building an open source lib C/C++ for Android development using Android NDK. I had got code from Github and created my own jni folder under source code. In that jni folder, I created some C source files and included many header files in open source lib. But when I built, I had got failed log:
fatal error: bits/libc-header-start.h: No such file or directory
I checked and saw that file "libc-header-start.h" existed in /usr/include/x86_64-linux-gnu/bits/ folder of Ubuntu system but when building, it can not link to that header file
So can I use Ubuntu system header file in my Android NDK lib?
No, you should not use Ubuntu (or any other host) includes or libs to build an Android NDK library. NDK cross-compiles your code for the Android targets. Not all C++ projects on GitHub may be ported easily to Android. If they use CMake, these scripts often need adaptations for Android NDK. If they use automake tools, tuning the build scripts may be quite painful.
So can I use Ubuntu system header file in my Android NDK lib?
NO. You have to use all the Android NDK specific headers and libs for your NDK compilation, i.e. those inside your NDK folders.
Here is an example for Android JNI programming: https://github.com/russell-shizhen/JniExample
First step: I use QtCreator to compile a bunch of libraries (.so files) + a GUI test program to test those libraries on an Android device.
Second step: After I tested them, I re-compile the libraries without the GUI test program and send them to a client who's going to integrate those .so file in its own Andoid application (generating and apk), not using QtCreator anymore. I do this step using QtCreator (because it's setup, very easy for me to just remove the GUI test program and hit compile), but I'm pretty sure they could also be compiled directly using ndk-build if I work on writting the correct make files for that.
When I re-compile the libraries, there's still a "Android build SDK" option under "Build Android APK" set to "android-22" in QtCreator. However, my client generates its final app for "android-19". And we are wondering if this could be a problem.
My understanding is that my .so files generated in "second step" are built using the NDK only (SDK is not used, so android API version "android-22" is irrelevant as I do not generate any APK...). So there should be no compatibility issue when those .so files are integrated in an application, as far as the same NDK version is used.
Am I right?
I am using Eclipse to build an Android app that uses Renderscript. I include
renderscript.target=18
renderscript.support.mode=true
in my project.properties file.
Everything is running fine except that by default, Eclipse creates an apk which has a directory for all three platforms supported by Renderscript: x86, mips, armeabi-v7a. However, I am only supporting armeabi-v7a (the x86 and mips directories only contain the two .so files for Renderscript). This becomes important when publishing to the Google Play store, which uses the directories to figure out what native platform the app supports.
How do I specify that the x86 and mips platform directories should not be created?
After your apk has been generated, you can use the zip command:
zip -d your.apk path_or_files_to_be_removed_inside_the_apk
Note that you will need to sign again your apk after altering its content.
I would strongly recommend you to migrate to Android Studio where you will find more flexibility with gradle. Eclipse is not supported officially anymore.
We have a native .so file for 32-bit Android. We need to port it to 64-bit Android code (for Android L). We are not using NDK to build. We use make files and arm-linux-androideabi-g++ with command line options to build our source.
Can someone please let me know how to port our code to 64-bit Android platform?
You'll need to create a new standalone toolchain (same process you used to generate arm-linux-androideabi-g++) for arm64 (requires NDK r10).
http://www.kandroid.org/ndk/docs/STANDALONE-TOOLCHAIN.html
On a mac OS X I run ndk which generates some .so libraries which in theory should be reusable on windows. However, when I eclipse recompile my Android project on windows I get different apk size and it runs differently than when the whole eclipse build is done on Mac. Only building on the mac works. Not taking the .so files from the mac ndk build, and reusing them in the windows build. Its either that or something different about how macs and windows builds apk files that I don't understand. The problem with the windows generated apk is that it has memory over consumption not seen on the apk generated solely on osx.
So to clarify this (ON MAC OS X) works:
1) run ndk on osX generate .so files
2) OS X eclipse compile android app and deploy on device.
3) OS X eclipse run apk on device.
the generated apk of course runs on all devices.
This (ON WINDOWS) does NOT work:
1) on windows use .so generated on osx ndk build.
2) windows eclipse compile android app using the .so files generated by ndk on OS X.
3) eclipse run apk on device. The apk is of a different byte count and although it loads, it now generates memory errors unlike the apk developed solely on the OS X.
Thanks!
You can compile cross platform code (aka NDK) on OSx (MAC) and get *.so, *.a files.
After build Android project (a.e create APK) with Eclipse on Windows.
It should work.
(I did it for Linphone Android with core written on pure C)