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.
Related
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
Recently I have upgraded firebase crashlytics SDK to version 17.2.1 (NDK-version). This provide third party library libcrashlytics.so for artitecture armeabi-v7a and arm64-v8a for arm based 32-bit devices and 64-bit drvices. But my app is built for armeabi architecture for 32-bit devices and not for armaebi-v7a.
So post app build, when all the libraries are merged by build gradle, I cannot see libcrashlytics.so library in armeabi folder.
...build/intermediates/merged_native_libs/.../out/lib/armeabi-v7a/libcrashlytics.so
...build/intermediates/merged_native_libs/.../out/lib/arm64-v8a/libcrashlytics.so
...build/intermediates/stripped_native_libs/.../out/lib/armeabi-v7a/libcrashlytics.so
...build/intermediates/stripped_native_libs/.../out/lib/arm64-v8a/libcrashlytics.so
So when I try to dlopen this library with dlopen("libcrashlytics.so", RTLD_LAZY | RTLD_LOCAL)); my app crashes in 32-bit mobile devices as it is not able to load libcrashlytics library. My app works fine with 64-bit architecture.
But after manually copying libcrashlytics.so library to ...build/intermediates/stripped_native_libs/.../out/lib/armaebi/ directory and then building it, solves the problem. In https://developer.android.com/ndk/guides/abis it is mentioned that armaebi-v7a is compatible with armaebi, so it should be fine.
So,
Is there any way to provide instruction to gradle to copy "libcrashlytics.so" located in armaebi-v7a to armaebi ?
Is there any other way to automate copying during build ?
Is there any other work around for my problem ?
Environment -
Gradle plugin version - 3.5.4
Gradle version - 5.4.1
NOTE: Due to few other reasons, I cannot move our app to support "armaebi-v7a"
In Android 8.1 we can build and install the application in the vendor partition in the AOSP build tree.
by using LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR_APPS)
After the installation, I found that the .apk file resides in the following path vendor/app/SampleApp/SampleApp.apk and data files are available in the data/data/.
And lib(pre-build .so libs) folder pointing to the vendor/app/SampleApp/SampleApp/libs but there is no folder like that.
I have extracted the application and found the lib files are available in .apk file.
What is the difference between the vendor application build and system build?
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?
Can anybody explain me what is the difference in 32-bit armeabi binaries compiled using ndk32-r10 build and ndk64-r10 build?
I am having several native libraries in my android project. Initially I was using android ndk-r9d build to compile these binaries for armeabi platform.
Now I have made some changes to one of the library and compiled it using ndk32-r10b build for armeabi.
Everything worked fine.
After this I compiled the same 32-bit binary with ndk64-r10b build for armeabi platform, which got compiled successfully. But at runtime it throws an error that it can not load/find library.
Please note that compilation succedded but it could not load the library at run time.
Can anybody tell me what is the difference in the 32-bit binaries built using ndk32 and ndk64?
Because according to my understanding ndk64 should be able to compile both 32-bit and 64-bit binaries as it is having options for both the platforms.
Is it related to any specific changes made for Android L in the binaries built using ndk64 build, if any?
Thanks for your help in advance.