Related
I've just received and read a newsletter from Google Play mentioning that from next year on, the store "will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions".
For those who haven't read it yet, it states:
64-bit support requirement in 2019
Platform support for 64-bit architectures was introduced in Android
5.0. Today, over 40% of Android devices coming online have 64-bit support, while still maintaining 32-bit compatibility. For apps that
use native libraries, 64-bit code typically offers significantly
better performance, with additional registers and new instructions.
In anticipation of future Android devices that support 64-bit code
only, the Play Console will require that new apps and app updates with
native libraries provide 64-bit versions in addition to their 32-bit
versions. This can be within a single APK or as one of the multiple
APKs published.
We are not removing 32-bit support. Google Play will continue to
support 32-bit apps and devices. Apps that do not include native code
are unaffected.
This change will come into effect in August 2019. We're providing
advance notice today to allow plenty of time for developers who don't
yet support 64-bit to plan the transition. Stay tuned for a future
post in which we'll take an in-depth look at the performance benefits
of 64-bit native libraries on Android, and check out the CPUs and
Architectures guide of the NDK for more info.
What practical changes will we need to make to perfectly comply with this new requirement when applicable?
According to an official email sent by the Google Play Team, the action required is:
If you haven't yet, we encourage you to begin work for the 64-bit
requirement as soon as possible. Many apps are written entirely in
non-native code (e.g. the Java programming language or Kotlin) and
will not need code changes.
Please note that we are not making changes to our policy on 32-bit
support. Google Play will continue to deliver apps with 32-bit native
code to 32-bit devices. The requirement means that those apps will
need to have a 64-bit version as well.
To help you make the transition, we've prepared documentation on how
to check whether your app already supports 64-bit and how to become
64-bit compliant.
We're also providing a high-level timeline below.
So, the linked documentation explains:
If your app uses only code written in the Java programming language or
Kotlin, including any libraries or SDKs, your app is already ready for
64-bit devices. If your app uses any native code, or you are unsure if
it does, you will need to assess your app and take action.
[...]
The simplest way to check for 64-bit libraries is to inspect the
structure of your APK file. When built, the APK will be packaged with
any native libraries needed by the app. Native libraries are stored in
various folders based on the ABI. It is not required to support every
64-bit architecture, but for each native 32-bit architecture you
support you must include the corresponding 64-bit architecture.
For the ARM architecture, the 32-bit libraries are located in
armeabi-v7a. The 64-bit equivalent is arm64-v8a.
For the x86 architecture, look for x86 for 32-bit and x86_64 for
64-bit.
The first thing to do is ensure that you have native libraries in both
of these folders.[...]
And, to build 64-bit libraries, you basically need to follow the instructions below:
Most Android Studio projects use Gradle as the underlying build
system, so this section applies to both cases. Enabling builds for
your native code is as simple as adding the arm64-v8a and/or x86_64,
depending on the architecture(s) you wish to support, to the
ndk.abiFilters setting in your app's 'build.gradle' file:
// Your app's build.gradle
apply plugin: 'com.android.app'
android {
compileSdkVersion 27
defaultConfig {
appId "com.google.example.64bit"
minSdkVersion 15
targetSdkVersion 28
versionCode 1
versionName "1.0"
ndk.abiFilters 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64'
// ...
Finally, a quick note:
The 64-bit version of your app should offer the same quality and
feature set as the 32-bit version.
By the way, this official video talks a little bit about it.
If you have no native (NDK) code, that is you only write Java/Dex code, then you don't need to do anything.
If you have native code (or libraries) then you need to supply their 64-bit versions.
As per documentation here, if your app is using native code or external library, for example, realm (in the picture below) which is based on native, then a support for 64-bit should be provided. If any of external libraries in your app which uses any C/C++ (native) should have both 32-bit and 64-bit architecture support otherwise you should make contact with the library owner. In Android Studio, we can check whether versions for both architectures are available by Build > Analyze APK and the following window appears:
If you are using NDK and creating native code, you should provide support for all architecture by enlisting them in the gradle as:
defaultConfig {
ndk.abiFilters = 'armeabi-v7a' 'arm64-v8a' 'x86' 'x86_64'
}
If your Android APK is not including 64-bit support, you need not to worry.
Go to Build -> Analyze APK, in Android Studio. You are able to see APK structure. Under lib, if you see armeabi-v7a libraries and if you do not have any arm64-v8a or x86_64 libraries, then your APK does not support 64-bit architecture.
Just go to app level build.gradle and add abiFilters in NDK under defaultConfig as below:
ndk {
abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
}
Step 1 :
app=> build.gradle (put below code in build.gradle)
android {
........
defaultConfig {
.........
ndk {
abiFilters = []
abiFilters.addAll(PROP_APP_ABI.split(':').collect{it as String})
}
........
}
.......
packagingOptions {
exclude 'lib/armeabi-v7a/libARM_ARCH.so'
}
}
Step : 2
gradle.properties
(put below line in gradle.properties)
PROP_APP_ABI=armeabi-v7a:arm64-v8a
Step 3 : Build propject again. Try to upload that apk to play store.
Adding
ndk {
abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
}
in the build.Gradle file under DefaultConfig. Note that push to play store 64-bit requirement is coming.
I tried this By Official Android Docs. Working Excellent.
In this Solution, I have Build Multi APKs You can see in Attachment...
Make Sure Your Compile Skd Version is 29 or Build Tools Version Is 29.0.3 Written Bellow:
Android {
compileSdkVersion 29
buildToolsVersion '29.0.3'
defaultConfig {
applicationId "com.myapp.sk"
minSdkVersion 21
targetSdkVersion 29
versionCode 2
versionName "1.0"
multiDexEnabled true
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
splits {
density {
enable true
reset()
include "mdpi", "hdpi"
}
abi {
enable true
reset()
include "x86", "x86_64"
}
}
}
// Map for the version code that gives each ABI a value.
ext.abiCodes = ['armeabi-v7a':1, x86:2, x86_64:3]
// For per-density APKs, create a similar map like this:
// ext.densityCodes = ['mdpi': 1, 'hdpi': 2, 'xhdpi': 3]
import com.android.build.OutputFile
// For each APK output variant, override versionCode with a combination of
// ext.abiCodes * 1000 + variant.versionCode. In this example, variant.versionCode
// is equal to defaultConfig.versionCode. If you configure product flavors that
// define their own versionCode, variant.versionCode uses that value instead.
android.applicationVariants.all { variant ->
// Assigns a different version code for each output APK
// other than the universal APK.
variant.outputs.each { output ->
// Stores the value of ext.abiCodes that is associated with the ABI for this variant.
def baseAbiVersionCode =
// Determines the ABI for this variant and returns the mapped value.
project.ext.abiCodes.get(output.getFilter(OutputFile.ABI))
// Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes,
// the following code does not override the version code for universal APKs.
// However, because we want universal APKs to have the lowest version code,
// this outcome is desirable.
if (baseAbiVersionCode != null) {
// Assigns the new version code to versionCodeOverride, which changes the version code
// for only the output APK, not for the variant itself. Skipping this step simply
// causes Gradle to use the value of variant.versionCode for the APK.
output.versionCodeOverride =
baseAbiVersionCode * 1000 + variant.versionCode
}
}
}
Multi-Aks Attachment
Native code: refers to an executable program that was compiled directly to the CPU instructions of the computer it is running on.
Non-native code: refers to an executable program that was compiled to the CPU instructions of the original Tandem architecture of the late 1970s and 1980s. When such a program is run, it cannot execute directly on the CPU of the computer it is running on. The NonStop operating system includes an interpreter for that original Tandem architecture, which is used to run such non-native code.
If your app uses only code written in the Java programming language or Kotlin, including any libraries or SDKs, your app is already ready for 64-bit devices. If your app uses any native code, or you are unsure if it does, you will need to assess your app and take action.
Does your app use native code?
The first thing to do is to check to see if your app uses any native code. Your app makes use of native code if it:
uses any C/C++ (native) code in your app.
links with any third party native libraries.
is built by a third party app builder that uses native libraries.
For more, visit the docs.
Option 1 - remove lib from APK.
Step 1 - convert the APK to ZIP and find lib folder; if you have lib folder, see the library dependency.
Step 2 - remove dependency from build Gradle.
Option 2 - Download 64-bit and 32-bit JAR file and add in your lib folder in app and build.
first open build.gradle module app and add these lines in order to remove .so files and add 64 bit liobraries
removing all .so files present in libs of apk
android {
compileSdkVersion 29
defaultConfig {
-----
-----
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
ndk {
abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
}
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
packagingOptions{
packagingOptions {
exclude 'lib/armeabi-v7a/libvudroid.so'
exclude 'lib/x86/libvudroid.so'
exclude 'lib/arm64-v8a/libvudroid.so'
}
}`
In my case, I was using a library (ESRI ArcGIS for Android) that makes use of OpenGL C libraries. Instead of the ndk.abiFilters... string that seems to fix everyone else's issues, I had to use the following:
ndk { abiFilters "armeabi-v7a", "arm64-v8a" }
Add this in your build.gradle
ndk.abiFilters 'arm64-v8a','x86_64'
I tried to install my app into Android L Preview Intel Atom Virtual Device, it failed with error:
INSTALL_FAILED_NO_MATCHING_ABIS
What does it mean?
INSTALL_FAILED_NO_MATCHING_ABIS is when you are trying to install an app that has native libraries and it doesn't have a native library for your cpu architecture. For example if you compiled an app for armv7 and are trying to install it on an emulator that uses the Intel architecture instead it will not work.
INSTALL_FAILED_NO_MATCHING_ABIS is when you are trying to install an app that has native libraries and it doesn't have a native library for your cpu architecture. For example if you compiled an app for armv7 and are trying to install it on an emulator that uses the Intel architecture instead it will not work.
Using Xamarin on Visual Studio 2015.
Fix this issue by:
Open your xamarin .sln
Right click your android project
Click properties
Click Android Options
Click the 'Advanced' tab
Under "Supported architectures" make the following checked:
armeabi-v7a
x86
save
F5 (build)
Edit: This solution has been reported as working on Visual Studio 2017 as well.
Edit 2: This solution has been reported as working on Visual Studio 2017 for Mac as well.
I'm posting an answer from another thread because it's what worked well for me, the trick is to add support for both architectures :
Posting this because I could not find a direct answer and had to look at a couple of different posts to get what I wanted done...
I was able to use the x86 Accelerated (HAXM) emulator by simply adding this to my Module's build.gradle script Inside android{} block:
splits {
abi {
enable true
reset()
include 'x86', 'armeabi-v7a'
universalApk true
}
}
Run (build)... Now there will be a (yourapp)-x86-debug.apk in your output folder. I'm sure there's a way to automate installing upon Run but I just start my preferred HAXM emulator and use command line:
adb install (yourapp)-x86-debug.apk
If you using Genymotion you need Installing ARM Translation and GApps
This is indeed a strange error that can be caused by multidexing your app. To get around it, use the following block in your app's build.gradle file:
android {
splits {
abi {
enable true
reset()
include 'x86', 'armeabi-v7a'
universalApk true
}
}
...[rest of your gradle script]
On Android 8:
apache.commons.io:2.4
gives INSTALL_FAILED_NO_MATCHING_ABIS, try to change it to implementation 'commons-io:commons-io:2.6' and it will work.
This solution worked for me. Try this,
add following lines in your app's build.gradle file
splits {
abi {
enable true
reset()
include 'x86', 'armeabi-v7a'
universalApk true
}
}
I know there were lots of answers here, but the TL;DR version is this (If you're using Xamarin Studio):
Right click the Android project in the solution tree
Select Options
Go to Android Build
Go to Advanced tab
Check the architectures you use in your emulator (Probably x86 / armeabi-v7a / armeabi)
Make a kickass app :)
i had this problem using bitcoinJ library (org.bitcoinj:bitcoinj-core:0.14.7)
added to build.gradle(in module app) a packaging options inside the android scope.
it helped me.
android {
...
packagingOptions {
exclude 'lib/x86_64/darwin/libscrypt.dylib'
exclude 'lib/x86_64/freebsd/libscrypt.so'
exclude 'lib/x86_64/linux/libscrypt.so'
}
}
this worked for me ... Android > Gradle Scripts > build.gradle (Module:app)
add inside android*
android {
// compileSdkVersion 27
defaultConfig {
//
}
buildTypes {
//
}
// buildToolsVersion '27.0.3'
splits {
abi {
enable true
reset()
include 'x86', 'armeabi-v7a'
universalApk true
}
}
}
The comment of #enl8enmentnow should be an answer to fix the problem using genymotion:
If you have this problem on Genymotion even when using the ARM translator it is because you are creating an x86 virtual device like the Google Nexus 10. Pick an ARM virtual device instead, like one of the Custom Tablets.
Visual Studio mac - you can change the support here:
this problem is for CPU Architecture and you have some of the abi in the lib folder.
go to build.gradle for your app module and in android, block add this :
splits {
abi {
enable true
reset()
include 'x86', 'armeabi-v7a'
universalApk true
}
}
In the visual studio community edition 2017, sometimes the selection of Supported ABIs from Android Options wont work.
In that case please verify that the .csproj has the following line and no duplicate lines in the same build configurations.
<AndroidSupportedAbis>armeabi;armeabi-v7a;x86;x86_64;arm64-v8a</AndroidSupportedAbis>
In order to edit,
Unload your Android Project
Right click and select Edit Project ...
Make sure you have the above line only one time in a build configuration
Save
Right click on your android project and Reload
In my case, in a xamarin project, in visual studio error removed by selecting properties --> Android Options and check Use Share run Times and Use Fast Deployment, in some cases one of them
In my case, I needed to download the x86 version of the application.
Go to https://www.apkmirror.com/
Search for the app
Select the first one in the list
Look at the top of the page, where is has [Company Name] > [Application Name] > [Version Number]
Click the Application Name
Click 'All Variants'
The list should contain an x86 variant to download
For genymotion on mac, I was getting INSTALL_FAILED_NO_MATCHING_ABIS error while installing my apk.
In my project there wasn't any "APP_ABI" but I added it accordingly and it built just one apk for both architectures but it worked.
https://stackoverflow.com/a/35565901/3241111
Basically if you tried Everything above and still you have the same error "Because i am facing this issue before too" then check which .jar or .aar or module you added may be the one library using ndk , and that one is not supporting 8.0 (Oreo)+ , likewise i am using Microsoft SignalR socket Library adding its .jar files and latterly i found out app not installing in Oreo then afterwards i remove that library because currently there is no solution on its git page and i go for another one.
So please check the library you are using and search about it if you eagerly needed that one.
In general case to find out which library dependency has incompatible ABI,
build an APK file in Android Studio (menu Build > Build Bundle(s)/APK(s) > Build APK(s)) // actual on 01.04.2020
rename APK file, replacing extension "apk" with extension "zip"
unpack zip file to a new folder
go to libs folder
find out which *.jar libraries with incompatible ABIs are there
You may try to upgrade version / remove / replace these libraries to solve INSTALL_FAILED_NO_MATCHING_ABIS when install apk problem
Just in case, this might help someone like me.
I had this same issue in Unity 3D. I was attempting to use the emulators from Android Studio.
So I enabled Target Architecture->x86 Architecture(although deprecated) in Player Settings and it worked!
In my case(Windows 10, Flutter, Android Studio), I simply created a new emulator device in Android Studio. This time, I have chosen x86_64 ABI instead of only x86. It solved my issue.
My emulator devices are shown in the screenshot below.
I faced this issue when moved from Android 7(Nougat) to Android 8(Oreo).
I have tried several ways listed above and to my bad luck nothing worked.
So i changed the .apk file to .zip file extracted it and found lib folder with which this file was there /x86_64/darwin/libscrypt.dylib so to remove this i added a code in my build.gradle module below android section (i.e.)
packagingOptions {
exclude 'lib/x86_64/darwin/libscrypt.dylib'
exclude 'lib/x86_64/freebsd/libscrypt.so'
exclude 'lib/x86_64/linux/libscrypt.so'
}
Cheers issue solved
Hi if you are using this library;
implementation 'org.apache.directory.studio:org.apache.commons.io:2.4'
Replace it with:
implementation 'commons-io:commons-io:2.6'
And the problem will be fixed.
This happened to me. I checked the SDK Manager and it told me the one I was using had a update. I updated it and the problem went away.
Quite late, but just ran into this. This is for Xamarin.Android. Make sure that you're not trying to debug in release mode. I get that exact same error if in release mode and attempting to debug. Simply switching from release to debug allowed mine to install properly.
In my case setting folowing options helpet me out
Somehow, this fix the issue out of no reason.
./gradlew clean assemble and then install the app.
We use old version of Scobbler in our project, and now we can't publish our updated apk because of new Google Play 64-bit requirement:
https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html
There are on only x32 lib files in our project, we have't necessary x64.
We bought it and we use it legal, but Scobbler closed their sources about year ago. So now we can't just download files from their site or git(as patchnotes says, Scobbler releaze library for x64 on last patches).
So, what should we do? Is there any way to find files for x64 support? Scobbler is very important for us, we can't replace it(we tried).
We write to their support several days ago, but no one response. As i think, no one will.
Check this link
Here you can see the change logs for the SDK
Android SDK change log from version 3.1.0 to version 3.2.0
New features
64 bit architecture for SDK
By using this version most of your methods might get changed.
An alterantive patch is to use this in build.gradle
android {
defaultConfig {
ndk {
abiFilters "armeabi", "armeabi-v7a", "x86"
}
}
}
Also add android.useDeprecatedNdk=true into gradle.properties
Finally create a new folder named armeabi under the libs and copy 32bit .so file into that folder.
Please check the Android SDK Public Release Change log from 3.2.0 to 3.3.0: https://developer.skobbler.com/changelog/android/3.3.0
Send mail to customer support if needed.
I've just received and read a newsletter from Google Play mentioning that from next year on, the store "will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions".
For those who haven't read it yet, it states:
64-bit support requirement in 2019
Platform support for 64-bit architectures was introduced in Android
5.0. Today, over 40% of Android devices coming online have 64-bit support, while still maintaining 32-bit compatibility. For apps that
use native libraries, 64-bit code typically offers significantly
better performance, with additional registers and new instructions.
In anticipation of future Android devices that support 64-bit code
only, the Play Console will require that new apps and app updates with
native libraries provide 64-bit versions in addition to their 32-bit
versions. This can be within a single APK or as one of the multiple
APKs published.
We are not removing 32-bit support. Google Play will continue to
support 32-bit apps and devices. Apps that do not include native code
are unaffected.
This change will come into effect in August 2019. We're providing
advance notice today to allow plenty of time for developers who don't
yet support 64-bit to plan the transition. Stay tuned for a future
post in which we'll take an in-depth look at the performance benefits
of 64-bit native libraries on Android, and check out the CPUs and
Architectures guide of the NDK for more info.
What practical changes will we need to make to perfectly comply with this new requirement when applicable?
According to an official email sent by the Google Play Team, the action required is:
If you haven't yet, we encourage you to begin work for the 64-bit
requirement as soon as possible. Many apps are written entirely in
non-native code (e.g. the Java programming language or Kotlin) and
will not need code changes.
Please note that we are not making changes to our policy on 32-bit
support. Google Play will continue to deliver apps with 32-bit native
code to 32-bit devices. The requirement means that those apps will
need to have a 64-bit version as well.
To help you make the transition, we've prepared documentation on how
to check whether your app already supports 64-bit and how to become
64-bit compliant.
We're also providing a high-level timeline below.
So, the linked documentation explains:
If your app uses only code written in the Java programming language or
Kotlin, including any libraries or SDKs, your app is already ready for
64-bit devices. If your app uses any native code, or you are unsure if
it does, you will need to assess your app and take action.
[...]
The simplest way to check for 64-bit libraries is to inspect the
structure of your APK file. When built, the APK will be packaged with
any native libraries needed by the app. Native libraries are stored in
various folders based on the ABI. It is not required to support every
64-bit architecture, but for each native 32-bit architecture you
support you must include the corresponding 64-bit architecture.
For the ARM architecture, the 32-bit libraries are located in
armeabi-v7a. The 64-bit equivalent is arm64-v8a.
For the x86 architecture, look for x86 for 32-bit and x86_64 for
64-bit.
The first thing to do is ensure that you have native libraries in both
of these folders.[...]
And, to build 64-bit libraries, you basically need to follow the instructions below:
Most Android Studio projects use Gradle as the underlying build
system, so this section applies to both cases. Enabling builds for
your native code is as simple as adding the arm64-v8a and/or x86_64,
depending on the architecture(s) you wish to support, to the
ndk.abiFilters setting in your app's 'build.gradle' file:
// Your app's build.gradle
apply plugin: 'com.android.app'
android {
compileSdkVersion 27
defaultConfig {
appId "com.google.example.64bit"
minSdkVersion 15
targetSdkVersion 28
versionCode 1
versionName "1.0"
ndk.abiFilters 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64'
// ...
Finally, a quick note:
The 64-bit version of your app should offer the same quality and
feature set as the 32-bit version.
By the way, this official video talks a little bit about it.
If you have no native (NDK) code, that is you only write Java/Dex code, then you don't need to do anything.
If you have native code (or libraries) then you need to supply their 64-bit versions.
As per documentation here, if your app is using native code or external library, for example, realm (in the picture below) which is based on native, then a support for 64-bit should be provided. If any of external libraries in your app which uses any C/C++ (native) should have both 32-bit and 64-bit architecture support otherwise you should make contact with the library owner. In Android Studio, we can check whether versions for both architectures are available by Build > Analyze APK and the following window appears:
If you are using NDK and creating native code, you should provide support for all architecture by enlisting them in the gradle as:
defaultConfig {
ndk.abiFilters = 'armeabi-v7a' 'arm64-v8a' 'x86' 'x86_64'
}
If your Android APK is not including 64-bit support, you need not to worry.
Go to Build -> Analyze APK, in Android Studio. You are able to see APK structure. Under lib, if you see armeabi-v7a libraries and if you do not have any arm64-v8a or x86_64 libraries, then your APK does not support 64-bit architecture.
Just go to app level build.gradle and add abiFilters in NDK under defaultConfig as below:
ndk {
abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
}
Step 1 :
app=> build.gradle (put below code in build.gradle)
android {
........
defaultConfig {
.........
ndk {
abiFilters = []
abiFilters.addAll(PROP_APP_ABI.split(':').collect{it as String})
}
........
}
.......
packagingOptions {
exclude 'lib/armeabi-v7a/libARM_ARCH.so'
}
}
Step : 2
gradle.properties
(put below line in gradle.properties)
PROP_APP_ABI=armeabi-v7a:arm64-v8a
Step 3 : Build propject again. Try to upload that apk to play store.
Adding
ndk {
abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
}
in the build.Gradle file under DefaultConfig. Note that push to play store 64-bit requirement is coming.
I tried this By Official Android Docs. Working Excellent.
In this Solution, I have Build Multi APKs You can see in Attachment...
Make Sure Your Compile Skd Version is 29 or Build Tools Version Is 29.0.3 Written Bellow:
Android {
compileSdkVersion 29
buildToolsVersion '29.0.3'
defaultConfig {
applicationId "com.myapp.sk"
minSdkVersion 21
targetSdkVersion 29
versionCode 2
versionName "1.0"
multiDexEnabled true
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
splits {
density {
enable true
reset()
include "mdpi", "hdpi"
}
abi {
enable true
reset()
include "x86", "x86_64"
}
}
}
// Map for the version code that gives each ABI a value.
ext.abiCodes = ['armeabi-v7a':1, x86:2, x86_64:3]
// For per-density APKs, create a similar map like this:
// ext.densityCodes = ['mdpi': 1, 'hdpi': 2, 'xhdpi': 3]
import com.android.build.OutputFile
// For each APK output variant, override versionCode with a combination of
// ext.abiCodes * 1000 + variant.versionCode. In this example, variant.versionCode
// is equal to defaultConfig.versionCode. If you configure product flavors that
// define their own versionCode, variant.versionCode uses that value instead.
android.applicationVariants.all { variant ->
// Assigns a different version code for each output APK
// other than the universal APK.
variant.outputs.each { output ->
// Stores the value of ext.abiCodes that is associated with the ABI for this variant.
def baseAbiVersionCode =
// Determines the ABI for this variant and returns the mapped value.
project.ext.abiCodes.get(output.getFilter(OutputFile.ABI))
// Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes,
// the following code does not override the version code for universal APKs.
// However, because we want universal APKs to have the lowest version code,
// this outcome is desirable.
if (baseAbiVersionCode != null) {
// Assigns the new version code to versionCodeOverride, which changes the version code
// for only the output APK, not for the variant itself. Skipping this step simply
// causes Gradle to use the value of variant.versionCode for the APK.
output.versionCodeOverride =
baseAbiVersionCode * 1000 + variant.versionCode
}
}
}
Multi-Aks Attachment
Native code: refers to an executable program that was compiled directly to the CPU instructions of the computer it is running on.
Non-native code: refers to an executable program that was compiled to the CPU instructions of the original Tandem architecture of the late 1970s and 1980s. When such a program is run, it cannot execute directly on the CPU of the computer it is running on. The NonStop operating system includes an interpreter for that original Tandem architecture, which is used to run such non-native code.
If your app uses only code written in the Java programming language or Kotlin, including any libraries or SDKs, your app is already ready for 64-bit devices. If your app uses any native code, or you are unsure if it does, you will need to assess your app and take action.
Does your app use native code?
The first thing to do is to check to see if your app uses any native code. Your app makes use of native code if it:
uses any C/C++ (native) code in your app.
links with any third party native libraries.
is built by a third party app builder that uses native libraries.
For more, visit the docs.
Option 1 - remove lib from APK.
Step 1 - convert the APK to ZIP and find lib folder; if you have lib folder, see the library dependency.
Step 2 - remove dependency from build Gradle.
Option 2 - Download 64-bit and 32-bit JAR file and add in your lib folder in app and build.
first open build.gradle module app and add these lines in order to remove .so files and add 64 bit liobraries
removing all .so files present in libs of apk
android {
compileSdkVersion 29
defaultConfig {
-----
-----
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
ndk {
abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
}
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
packagingOptions{
packagingOptions {
exclude 'lib/armeabi-v7a/libvudroid.so'
exclude 'lib/x86/libvudroid.so'
exclude 'lib/arm64-v8a/libvudroid.so'
}
}`
In my case, I was using a library (ESRI ArcGIS for Android) that makes use of OpenGL C libraries. Instead of the ndk.abiFilters... string that seems to fix everyone else's issues, I had to use the following:
ndk { abiFilters "armeabi-v7a", "arm64-v8a" }
Add this in your build.gradle
ndk.abiFilters 'arm64-v8a','x86_64'
I have a bit unusual problem - my Android app contains native libs and I build native libs for armeabi-v7a and x86. However, now I need to integrate a third party library into my app which also contains native libraries (third party library is Crashlytics which I included via Maven from my build.gradle.). The problem is that third party library's AAR provides all arhitectures (armeabi, arm64-v8a, armeabi-v7a, mips, mips64, x86 and x86_64) and my app only supports armeabi-v7a and x86 (arm64-v8a is planned for near future), so when final apk is built it contains 3rd party library's all ABI's and only x86 and armeabi-v7a ABI's of my native code. This causes my app to crash when launched on arm64 device like Galaxy S6.
My question is: is it possible to include only selected ABI's from 3rd party AAR?
Please note that I am aware of APK splits, but this only solves my problem partially, i.e. it works only if I distribute my app via Play Store. Although Play Store supports beta test distribution, the propagation of updated APK is rather slow, so prior pushing an update to app's PlayStore beta channel, we push an update via Crashlytics' beta distribution system, which is much faster. The problem is that Crashlytics' distibution system does not support APK splits (or am I wrong?). Therefore, I actually need to build an "universal" APK that will contain only selected ABIs. How to achieve that?
Although I would be satisfied even with Crashlytics'-specific answers (like for example, how to distribute APK splits via their beta channel), I would be much more satisfied with solution for building "universal" APK that contains only selected ABIs, because at our company we also provide SDKs to our clients as AAR archives that contain only supported architectures and we would like to instruct them how to handle case when they integrate our SDK with other SDKs that have different ABI's supported.
I am using latest stable Android studio (1.2.1.1), gradle 2.4 and android gradle plugin version 1.2.3.
packagingOptions {
exclude 'lib/arm64-v8a/libcrashlytics-envelope.so'
exclude 'lib/arm64-v8a/libcrashlytics.so'
exclude 'lib/armeabi/libcrashlytics-envelope.so'
exclude 'lib/armeabi/libcrashlytics.so'
exclude 'lib/mips64/libcrashlytics-envelope.so'
exclude 'lib/mips64/libcrashlytics.so'
exclude 'lib/mips/libcrashlytics-envelope.so'
exclude 'lib/mips/libcrashlytics.so'
exclude 'lib/x86_64/libcrashlytics-envelope.so'
exclude 'lib/x86_64/libcrashlytics.so'
}
This works for me:
(e.g: only armeabi & armeabi-v7a)
build.gradle
android{
defaultConfig{
ndk{
abiFilters "armeabi", "armeabi-v7a"
}
}
}
Mike from Fabric and Crashlytics here. With Splits, currently, we don't know in advance which density to provide the tester, so just add this line to your specific flavor or variant, to use the universal APK that is generated.
ext.betaDistributionApkFilePath = "path to the universal split APK"
Also, if you're using NDK crash reporting, in case it matches the crash you're seeing, check out this link.
I had the same problem as you, but you actually helped me with the link you posted about APK Splits!
In your case, try to add the following to your build.gradle inside the android closure:
splits {
abi {
enable true
reset()
include 'armeabi-v7a', 'x86'
universalApk true
}
}
The trick in there is to set the universalApk to true in order to generate only one APK with all the defined architectures, instead of splitting them up in several APKs.
Also don't forget the reset() which removes all the default values.