I have an Android Studio projet that depends on an external .so file compiled with another IDE. Whenever my .so is linked, I copy and paste it into the src/main/jniLibs/armeabi-v7a folder of my Android project, erasing the existing one, if any.
However, most of the time, it seems like Android Studio is not taking that change into account and keeps reusing the old version of the .so file. Sometimes it works, sometimes it doesn't, and I have not figured out what exactly is causing it to or not to work.
How can I do for the .so file to be updated ? I saw an SO answer providing a piece of gradle script to manually copy the .so file, but it doesn't fit my particular case since I have multiple .so files, one debug and one release for each CPU.
Related
We've recently migrated from VS2017 to VS2019, building Xamarin Forms applications. We've had no problems with obfuscation for years and years, but now we've got a showstopper. To summarise: the project DLL inside the final APK file is the un-obfuscated version, not the obfuscated version.
If we build the Android app normally (in a Release configuration) it works fine: decompiling the file shows the obfuscated code as expected - completely unintelligible. It also successfully copies this from its working 'dfout' folder (under 'obj') to the 'bin' folder, so the build process propogates the obfuscated file as it should; everything is cool.
But...when you run 'Archive' to create an APK file...things work differently. After many hours of close examination we worked out exactly is happening, but we don't know why, and how to fix it: the project DLL (that should go inside the APK) is getting taken from the un-obfuscated code. The obfuscation then runs after the packaging has completed, leaving the correct DLLs in the 'obj' and 'bin' folders, but the one inside the packaged APK is the un-obfuscated version.
What on earth is going on here?
Found the solution to this in the comment thread of another StackOverflow question.
Basically it's an issue with Dotfuscator working with VS2019, which requires some new Dotfuscator targeting files to work. Initially these too didn't work, but after deleting all bin and obj folders and restarting VS in Admin mode did the trick.
Dotfuscator obfuscates stand alone assembly but not the APK archive
I am facing a strange problem for which I am totally unable to find the correct reason.
When I build an android project on my system(using eclipse and OS CentOS: Linux(Fedora)), the .apk size is 15Mb while when I compile the same code on my colleague's system(using eclipse On windows XP), the build size is 7Mb which is half the size of .apk build on my system.
Please help...
Check your /lib and /res folder if you are including unwanted libs and unwanted resources
The problem was in my libs.
There were .so files in my libs that were not being committed to Svn as subclipse by default ignores .so files . I found the issue here I fail to commit a .so library file using subclipse
and the accepted answer of this question was perfect solution.
So now the .Apk on my colleague's system is same size as on mine(15mb).
I found a similar problem when moving source files from Windows to Linux. It seems there are various files that Windows sometimes adds to project folders such as Thumbs.db which, depending on the amount of project resources, can get fairly sizeable. On Windows file systems, these files are most likely detected as hidden when Eclipse/Android SDK reads through them to build the APK, on Linux however these would not be considered hidden and therefore could be getting bundled with the APK.
It would be worth checking the contents of the folders on both systems for hidden files and clean them.
When I install my app on a genymotion simulater device,it can not be installed well,on console I got "INSTALL_FAILED_CPU_ABI_INCOMPATIBLE"
I trid another app,it installed fine.I do not know why.
The application (certainly a game) must be ARM only.
Genymotion is a x86 platform, so compile the application to target x86.
You may be able to install ARM support manually :
http://forum.xda-developers.com/showthread.php?t=2528952
If you are using IntelliJ it may be related to the project's default configuration. IntelliJ will assume, unless otherwise specified, that Native libraries will be stored in the Libs folder. This is usually where developer store their JAR libraries. IntelliJ build process will package up the JAR file into the Native file folder in the APK.
If you experiencing this problem, you can find a good How-to:
INSTALL_FAILED_CPU_ABI_INCOMPATIBLE Intellj
This helped to resolve the issue I had.
You might want to check out my answer here:
INSTALL_FAILED_CPU_ABI_INCOMPATIBLE on device using intellij
I know it's written for IntelliJ, but you could be running into a similar issue with Eclipse where it thinks that some normal Java files or jar libraries are native code and including it in the compiled APK. A quick way to find out is to open up the final APK (it's just a jar file, so most utilities should be able to decompress it) and make sure that the only things you see are META-INF, res, AndroidManifest.xml, classes.dex, and resources.arsc. It's possible that there are other valid files in a normal Java Android application, but in general if you see anything else in there, particularly a libs folder, it's probably the result of the compilation process thinking that those other things are native libraries (compiled C/C++ code using the JNI).
If this is the case, you'll need to configure Eclipse to not interpret the Java libraries you're using as native code. Now, I don't personally use Eclipse so I don't know where the proper settings would be, but based off of this answer, it looks like Eclipse automatically assumes that the libs folder in the root of your project contains native libraries. The easiest solution may be to move any Java libraries you are using into a different folder (such as libraries).
http://blog.iteedee.com/2014/02/android-install_failed_cpu_abi_incompatible-intellj/
The INSTALL_FAILED_CPU_ABI_INCOMPATIBLE error is generated when you attempt to install an android application on a device with an unsupported CPU architecture. This error is usually related to the native libraries that are not packaged up for the device’s CPU architecture (ie: x86, ARMv6, ARMv7, etc).
Now, if you have an application that doesn’t use any native libraries or *.so file you might be scratching your head on this one. If you use IntelliJ IDEA IDE for your android development it might be packaging all of your related .JAR file in to the Native Library file location in your APK.
The cause of the same problem was different in my case.
I had added some dependency jars in /libs directory of my Android app project. One of these jars had exported library in jar format; i.e. a jar within a jar file. I've noticed that the apk created using jars with such structure are incompatible with x86 based devices (don't know why).
I have an Android Apps (A) project that depends on a Library project (B). The library project contains code as well as third-party jar files and some other jars that were exported from projects C and D. In Eclipse, I have project B specified as a library project.
However, when I connect my device and run project A (Run As -> Android Application), it crashes on the device and when I examine the LogCat output, there is a NoClassDefFoundError exception for one of the classes that exists in the jar files of project C.
When I unpack the B.jar file in Project B's bin folder, it does not contain anything else besides the META-INF/ folder with an empty MANIFEST.MF file. So this indicates that something seems to be going wrong someplace, but I'm unable to figure it out.
Could anybody help me with this issue?
Are you working with the latest ADT plugin and SDK revision? That is rev 22.x. If so there has been an important change to the dependency management.
Possible solution
For some reason the contents of the Order and Export tab has completely changed and you now have to export the Android Private Libraries from your library projects. See screenshot below:
More details
The tricky part of this change is that your project still compiles properly in Eclipse so you're not aware of any issues. Until you deploy the app on an emulator or device and you get the ClassDefNotFoundException on any call of a library project.
Not confirmed but I believe this is related to recent changes for maven support, also related to android studio preview
Similar change in the past
This reminds me of a similar change in the update to rev 17 where the lib folder suddenly changed to libs and all content from the original lib folder wasn't packaged so you wouldn't see any issues in eclipse. Only once installed on a device.
More information that 'issue' is available on this link. If you search on stackoverflow for "sdk 17" and "classdefnotfound' you'll also get enoug questions about that change.
Pretty much exact duplicate of Add a native lib to an APK. Since there was no answer I decided to ask again.
I have an Android project. I have an .so library built with android NDK. And I want to use this .so in my project, preferrably - without using NDK.
So, how do I tell Eclipse (or Android tools) that I need certain .so to be built into my APK?
It's actually easier than I expected. All I had to do is place the .so in libs/armeabi-v7a - Eclipse saw it and integrated into APK.
However, I've made this project by copying from another Eclipse project, which was actually building this .so from source. So, I think there were some settings that I would otherwise need to set. Feel free to add corrections or edit my answer.