For some reason my app is not 64-bit compatible.
My first thought was that it my be the lib files. I checked the resulting apk: I have arm64-v8a, armeabi, armebi-v7a, mips, x86 which all contain the same-named .so files. So, I'm thinking it is maybe because x86_64 is missing? But, I have another project running the exact same libs which IS 64-bit compatible according to the play dashboard. I can't see any difference between the two lib or gradle setups.
Has anyone encountered something similar?
UPDATE: Here is the resulting libs from analizing the apk:
Like I stated above, there are .so files for all except x86_64. Could this be the issue? Do you HAVE to have .so files for both arm64-v8a AND x86_64? And why would this not be an issue for my other projects?
Another Update:
Ok, so I THINK its not working cause I have x86 and not x86_64. Docs say " It isn't required to support every 64-bit architecture, but for each native 32-bit architecture you support you must include the corresponding 64-bit architecture." ... does this mean I can just remove x86 and it should work fine? Also, is it a good idea to remove x86? Does it remove support for many devices?
as described in official documentation
you should add ndk.abiFilters :
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
to you app build.gradle file
Ok so I figured it out.
It seems that I managed to 'trick' google into thinking my apps were 64-bit compatible. Just because the x86_64 FOLDER was available, I guess the google console assumed it contained the required libraries. The problem was that the x86_64 libs were missing. My solution, though not ideal, was to remove the x86 libraries (small percentage of device support anyway) so that I don't need x86_64.
SO, yay :) all my apps are now 64-bit compliant (although I've lost SOME device support).
Related
I am working with Xamarin Forms and I published the Android app ad-hoc to disc.
What I would like to do is to give the apk to some people to test by uploading it to a web site I have so they can download it. Here's what was created:
com.xx.xx-arm64-v8a.apk
com.xx.xx-armeabi-v7.apk
com.xx.xx-x86_64.apk
com.xx.xx-x86.apk
com.xx.xx.apk
My question is twofold. Why does it create four apps and which of those should I give to the person? I assume it's okay to give the last in the list but if that's the case then why are the others created?
I also heard something about a new feature with Android that would allow smaller builds and just let a person download the build that is needed for their device. Can someone tell me if I could use that with these apks and if so how I would do it.
Thanks
Here are the list of options that I have selected:
Please open your Android Options, If you enable the Generate one package (.apk) per selected ABI selection, you will get serveral .apk file. If you want to generate one .apk file, just unselect it like following screenshot.
If you want to enable the Generate one package (.apk) per selected ABIselection. you can give the .apk file by Users' device(CPU Architectures).
Xamarin.Android supports the following architectures:
armeabi – ARM-based CPUs that support at least the ARMv5TE instruction set. Note that armeabi is not thread-safe and should not be used on multi-CPU devices.
Note
As of Xamarin.Android 9.2, armeabi is no longer supported.
armeabi-v7a – ARM-based CPUs with hardware floating-point operations and multiple CPU (SMP) devices. Note that armeabi-v7a machine code will not run on ARMv5 devices.
arm64-v8a – CPUs based on the 64-bit ARMv8 architecture.
x86 – CPUs that support the x86 (or IA-32) instruction set. This instruction set is equivalent to that of the Pentium Pro, including MMX, SSE, SSE2, and SSE3 instructions.
x86_64 CPUs that support the 64-bit x86 (also referred as x64 and AMD64) instruction set.
If you want to know more details about CPU Architectures, you can refer to this thread.
https://learn.microsoft.com/en-us/xamarin/android/app-fundamentals/cpu-architectures?tabs=windows
while you are creating an apk Please make sure your Architecture should be armeabi-7a and armeabi-v8a in Project Properties - > Android Options -> Advanced.
after that Clean Solution.
than Please go for .apk Archive it will create simple Signed Apk which you can distribute.
Hope it helps.
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 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 have a few native libraries that are fairly big and bloating the application binary size. I looked into APK splitting but maintaining and QAing multiple APKs is not something I want to do.
So I'd like to exclude unused architectures in my release build flavour using the ndk.abiFilters Gradle property. (The debug builds I want to leave alone so that I can run the HAXM-accelerated emulator on x86).
I was thinking of just having armeabi-v7a and arm64-v8a in my release flavour, but I'm not sure whether it is worth worrying about the market share of the other architectures I'm dropping. After a lot of looking around I cannot find any reference to market share of ARMv6 (armeabi), MIPS, x86 or x86_64. My intuition tells me that the latter three are almost non-existent, but I'm not sure about ARMv6.
I found this link on a forum that has a list of phones that use various architectures. Is there something more reliable somewhere? Maybe with % of users similar to the Android version dashboard?
Anything else I may miss if I just build my native libs for armeabi-v7a and arm64-v8a (or armeabi, armeabi-v7a and arm64-v8a)?
First off, if you're worring about binary size, you don't really need arm64-v8a, all those devices can run the armeabi-v7a binaries just fine. Only if you really need to cram the last extra performance out of it, it might be worthwhile.
As for armeabi and ARMv6; Android itself doesn't officially support it any longer, since Android 4.4 (October 2013) - and since Android 4.0 it should be much less common (from that version, AOSP source requires modifications to still build for ARMv6). So in practice, if you aren't supporting versions below 4.4, you can drop that one without any significant loss.
Also, for x86; many of those devices ship with surprisingly decent emulation of arm binaries, so those can manage with the armeabi-v7a version just fine as well.
EDIT: The above was written in 2015; these days Play Store requires that apps include support for arm64-v8a. But these days the next question is more about whether you need to include armeabi-v7a at all, or if the market share of 32 bit devices is small enough to drop support for.
Including additional architectures will no longer have any impact on the binary size when using app bundles, as in that case Google Play will serve each device only the binaries that apply to that particular device. Not only that, but also application updates will be way smaller and faster.
Leaving the previous information for projects still not using app bundles:
Unfortunately, the Android Dashboard, as useful as it is, does not provide architecture information, nor does Google Analytics.
The Unity statistics used to provide statistics per architecture and CPU features. Note, however, that these are not general statistics, but only cover users of Unity applications/games. The information doesn't seem to be available in a public link anymore, so I have replaced the direct links with the latest snapshots in archive.org.
I was stuck with this problem when using Mapbox, then later found this article which was very useful.
Based on the below picture you just need armeabi-v7a and x86. Then based on Jose Gómez answer, I only added armeabi-v7a and didn't have any problem at all.
So add this line to your app.gradle
android {
defaultConfig {
//other configs
ndk {
abiFilters "armeabi-v7a"
}
}
}
If you're still worried about 2% - 3% of those who use x86 architecture, like ASUS ZenFone and lenovo phones then use this config instead in app.gradle
ndk {
abiFilters "armeabi-v7a", "x86"
}
Also for genymotion emulators you should use x86 architecture
UPDATE
If you get this error while publishing the apk in play store
Then use this
ndk {
abiFilters "armeabi-v7a", "arm64-v8a"
}
And finally, I suggest you use app bundle for releasing the APK
When I read #mstorsjo answer I was a little bit confused how to really use only one (or two) native libs, even though it's quite simple and straightforward. Therefore, I will give here an example and some more explanation (based on my further research).
For each supported architecture we have to create a specific folder in the jniLibs folder and drop the .so file there. As an example, for supporting armeabi-v7a (32bit) and arm64-v8a (64bit):
|--app
|--|--src
|--|--|--main
|--|--|--|--jniLibs
|--|--|--|--|--armeabi-v7a
|--|--|--|--|--|--.so Files
|--|--|--|--|--arm64-v8a
|--|--|--|--|--|--.so Files
With armeabi-v7a you support more than 90% of the available devices, but since it is 32bit architecture, running it on 64bit devices will result in an loss of performance (20-30%) {1}. For each specific case it can be quite handy to check the actual amount of supported devices, which can be done within the Google Play Console in the Release management > Device catalog section, by specifying ABI as filter.
Attention
When you don't add binaries for all architectures you have to be aware of the following:
If your app contains any other native libraries, you'll have to make sure you only have the same versions of them as well. That is due to Android demanding that all loaded native libraries be built for the same architecture. For example, if the first native library loaded is armeabi-v7a, Android will look ONLY for armeabi-v7a libraries on all System.loadLibrary() calls after that. If it doesn't find that exact architecture, it'll throw the java.lang.UnsatisfiedLinkError exception. {1}
I ran into this problem because some of my dependencies used native libraries, whereby armeabi-v7a couldn't be loaded anymore.
Background
I've recently started to develop some code using the NDK, and I've thought of a possible portability problem that could occur while developing using NDK.
The problem
Since NDK uses native code, it needs to be compiled per CPU architecture. This is a problem since the user needs to run the app no matter what CPU the device has.
Possible solutions I've found so far
I've noticed I can modify the file "jni/Application.mk" and use:
APP_ABI := armeabi armeabi-v7a x86
however, I don't know what I should do from this step on. Will the app contain all of the compiled code for each of the CPU architectures and automatically choose the correct one when running itself?
Also, what if there will be another CPU architecture that is unknown?
What will happen if I try to run the app on Google TV, which according to what I remember doesn't support the NDK at all?
Another solution I've found is the multi-apk support. However, I'm not sure I understand it. Does it all mean that you create the same APK, each time with a different configuration? No special automation tool from ADT to help with that?
If you don't set APP_ABI at all, or use
APP_ABI := all
in your Application.mk, then ndk-build will build for all architectures supported by your version of NDK. The latest one, to date r8d, will in addition to armeabi armeabi-v7a x86 build also for mips. When another architecture will be released, you will hopefully automatically get the APK built to support it.
When you application is installed on an Android device, the system will automatically choose the matching ABI version and install the correct shared libraries from the APK.
One drawback of this approach is that if the native libraries are big, your "monolithic" APK file may become huge. You can use the multi-APK approach to make user downloads smaller. The official site recommends: You should generally use multiple APKs to support different device configurations only when your APK is too large (greater than 50MB). You should carefully follow the version code guildlines if you choose this route.
Unfortunately, there are no trustworthy prophecies regarding NDK support on Google TV, but there seem to be no technical justification for its current unavailability. If and when it arrives, your ndk-build will take care of it automatically.
UPDATE Here is a simple process to maintain split APK. And by the way, the new Android TV does support NDK.
For the latest version (now r9) you have to specify in "jni/Application.mk"
APP_ABI := all
or
APP_ABI := armeabi armeabi-v7a x86 mips
without ./ndk_build will only build 'armeabi'