In my product I'm finding that when I install the APK file onto the Galaxy Nexus running android 4.0.1 the incorrect .so file is being installed. I have a so-called "fat" APK that includes native code for armeabi, armeabi-v7a and x86.
I'm finding that the .so file for the armeabi CPU ABI is being extracted from the APK file rather than the armeabi-v7a .so file. If I remove the "armeabi" folder from the APK file then the galaxy nexus correctly installs the .so file from the armeabi-v7a folder.
I've verified that the CPU ABI of the nexus is "armeabi-v7a" and its secondary ABI is "armeabi".
Has anyone else seen this problem, and have they found a way to work around the issue without removing the "armeabi" folder from their libs directory in the APK?
This seems to be a bug. I've tested it also by creating a small project using native code and indeed Galaxy Nexus chooses the wrong library (armeabi instead of armeabi-v7a).
I've reported this bug at http://code.google.com/p/android/issues/detail?id=25321 , with the sample project attached on the bug. Please star it to bring attention to Android engineers.
Seems that another StackOverflow question originates from this bug too: Android floating point math performance.
Related
I have this native library that only works on certain devices (armeabi, armeabi-v7a). It provides support for a custom HW module.
I detect and enable this library in java code based on the device that actually supports it. There are no issues on arm devices that do not provide this custom HW.
However, if I try to install my apk to an x86 device (or emulator), installation will fail with INSTALL_FAILED_NO_MATCHING_ABIS.
How can I link the library into the app that would avoid the reported error? I don't care if it's an ugly hack, as long as the app installs and starts.
The device checks the content of libs directory in the APK which is (in default Gradle configuration) copied from src/main/jniLibs. If there are subdirectories and none of them is x86, it will report this error. The easy solution here is to create subdirectory x86 with some dummy file.
I've attempted the solution outlined in building-combined-armv7-x86-apk-after-crosswalk-integration-in-an-ionic-project.
The great thing is that it creates a single apk file. But when I run my cordova application, I get the following alert:
Mismatch of CPU Architecture
The Crosswalk Project Service must be updated to match the CPU architecture of the device. Please install it from the app store, then restart app.
Looks like Crosswalk is not embedded in the combined apk.
Does anyone know how to embed Crosswalk in a combined apk?
After I had spent a lot time looking for I solved it:
If you open the ".apk" file generated with a compressor (like WinRar), inside folder "lib" you are going to see folders for different architectures (x86_64, x86, mips64, mips, armeabi-v7a, armeabi and arm64-v8a in my case). After inspect all them only x86 and armeabi-v7a have "libxwalkdummy.so" and "libxwalkcore.so" files, so I deleted which ones do not have it. So "lib" folder will only contain x86 and armeabi-v7a folders.
After that it seems that app works with crosswalk embedded.
I would like to know if there is any way to extract from an APK file the Application.mk information.
I particularly interested getting from the APK the supported CPU ABI's
if it's not possible reading the Application.mk file, then what is the right way knowing for sure what ABI's the apk is built for?
The tool that you can use server side to analyse an apk are unzip or, if you want to go deeper, apktool. When you unzip the apk you'll find a folder for each supported abi inside the lib folder of the uncompressed apk (x86, armeabi-v7a, etc.). The list of folder is the list of supported ABI, so you can get the information there. By code you can get the list of supported ABI of a device using the CPU_ABI for device running pre Lollipop and SUPPORTED_ABIS for devices running Android 21+.
About your question: the Application.mk is used to build the native library, so it's not zipped within the apk.
I have an application that uses the Metaio SDK to show some Augmented Reality stuff.
I have an issue where the app crashes when running it on Samsung Galaxy S6. Unfortunately I don't have any logcat logs for the issue.
I found this link http://helpdesk.metaio.com/questions/46459/android-sdk-arm64-support/46479.html talking about a similar issue, it relates to the 64-bit CPU on the Samsung S6, but I'm not sure if this is the cause of my issue.
Has anyboday seen something similar to this before?
it has good chances to be related to your issue.
When you install an APK on Android, the system will look for native libraries directories (armeabi, armeabi-v7a, arm64-v8a, x86, x86_64, mips64, mips) inside the lib folder of the APK, in the order determined by Build.SUPPORTED_ABIS.
If your app happen to have an arm64-v8a directory with other libs, the 32-bit metaio libs will not be installed as the libs aren't mixed. That means you have to provide the full set of your libraries for each architecture.
So, to solve your issue, you can remove your 64-bit libs from your build, or set abiFilters to package only 32-bit architectures:
android {
....
defaultConfig {
....
ndk {
abiFilters "armeabi", "armeabi-v7a", "x86", "mips"
}
}
}
If you get an error related to the use of the deprecated NDK support, add android.useDeprecatedNdk=true to a file named gradle.properties at the root of your project. Don't feel bad about using a deprecated integration, as using abiFilters is still the cleanest way atm to filter out 64-bit libs from an APK.
I know this is an old question and Metaio is not there anymore, but the solution was to upgrade the Metaio SDK to the latest availble version back then.
I want to publish 2 apk on google store (made with unity), using the multi-apk feature.
I looked on internet and i tried this :
Created a Application.mk at ProjectFolder/jni/
with only APP_ABI := x86 or APP_ABI := armeabi armeabi-v7a depending on the lib I wanted to use.
Created 2 apk with 2 version code with Unity 'device filtrer' settings to x86 or Ar Mv 7, depending on the apk I wanted to build.
Published both apk on google develloper console.
The Apk have not the same size, so different libs are used. (With both lib, the apk weight 16 mo more, with only arm, like ~8mo more and with only x86 like ~8.5mo).
The problem is, 'native platform' detected by google console is always 'armeabi-v7a, x86' (both architectures), no matter the apk.
So I get a error message on google console saying that both apk have exaclty same device compatibility.
(PS: if I want 2 differents apk, it's because each lib take 8mo on the final apk, so 16mo for an empty project. And with google size limitation for apk...)
Update :
Ok the probleme was from a plugin (everyplay).It had libs for x86 and arm architechture. The solution was to remove the x86 plugin lib before building the arm apk, and to remove arm plugin lib to build the x86 apk.
I also noticed that changing APP_ABI in Application.mk was not necessary, the unity parameter device filtrer override it.
If Google is pointing this out, it means that somewhere Unity is overriding / including files for x86 even when you're trying to build for ARM. Here's a couple of things you should do
Open Unity's Player Settings, go to the Android tab, select Other Settingsand under Configuration -> Device Filter select whatever architecture you want to build for (Default is both)
This one is a little more un-intuitive. Just because you do step 1 above, doesn't ALWAYS mean that only 1 architecture gets built. If a plugin, it it's /lib folder includes ANY files that are for both architectures, then both architectures are built. So you need to manually comb through each plugi folder and ensure that there's no such files.