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.
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'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'
In my app I'm using "de.mrmaffen:vlc-android-sdk:2.0.6" library and it's taking much storage but I can't find a smaller alternative.
So I decided as CommonsWare mentioned to use splits or product flavors but I can't get it to work.
I tried to follow the docs with no luck.
Any help appreciated.
Building the LibVLC Android SDK yourself
If you are using "de.mrmaffen:vlc-android-sdk:2.0.6", buid the LibVLC Android SDK yourself
As explained here, afterwards simply run this Gradle command: ./gradlew buildLibVlc
Building a specific version of the LibVLC Android SDK
cd vlc-android // if this folder doesn't exist yet, simply run ./gradlew cloneVlcAndroid
git tag // to list all release versions
git checkout {tag-name} // to checkout the git repo at the given tag
cd ..
./gradlew buildLibVlc // build it
Make sure you followed the Android compile instructions in terms of dependencies and check this:
git clone repo.
open up a command prompt in this repo. "cd" or change directory into
it.
git clone .
change directory into the vlc-android directory.
git tag
git checkout <tag_version>. In this case, 2.1.2.
cd ..
comment out both the compile/build of the build.gradle script that
you don't need.
./gradlew buildLibVlc
you should have a successful build with both the Java sources and
shared object (*.so) files in the jniLibs folder.
create a libs folder right next to the jniLibs folder if you
updated the gradle version.
Get it via Maven CentralJCenter
Just add this dependency to your project and you're good to go.
dependencies {
implementation 'de.mrmaffen:libvlc-android:2.1.12#aar'
}
I'm using this version. Remember to add JCenter to your project's build.gradle file:
allprojects {
repositories {
jcenter()
}
}
VLC Android SDK via JCenter supports the next ABIs: armeabi-v7a, arm64-v8a, x86 and x86_64.
You can filter specific ABIs in your app's build.gradle file (x86_64 and arm64-v8a are excluded):
android {
ndk {
abiFilters "armeabi-v7a", "x86"
}
}
It's possible to check included files in mrmaffen's repository and via recent Android Studio versions:
Configure multiple APKs for ABIs
Add an abi block inside
your splits block. In your abi block, provide a list of desired ABIs. Source
android {
...
splits {
// Configures multiple APKs based on ABI.
abi {
// Enables building multiple APKs per ABI.
enable true
// By default all ABIs are included, so use reset() and include to specify that we only
// want APKs for x86 and armeabi-v7a.
// Resets the list of ABIs that Gradle should create APKs for to none.
reset()
// Specifies a list of ABIs that Gradle should create APKs for.
include "x86", "armeabi-v7a"
// Specifies that we do not want to also generate a universal APK that includes all ABIs.
universalApk false
}
}
}
Build multiple APKs
Click Build > Build APK to build all APKs for the currently selected
module in the Project pane.
Gradle creates the APKs for each ABI
into the project's build/outputs/apk/ directory.
Configure Build Variants
This page builds on the Configure Your Build Overview to show you how you can configure build variants to create different versions of your app.
Combine abi filters and build variants
Exclude abi from apk
android {
productFlavors {
x86 {
ndk {
abiFilter "x86"
}
}
arm {
ndk {
abiFilters "armeabi-v7a", "armeabi"
}
}
}
}
Multi-APK through ABI and density splits
How to reduce the number of APKs with ABI splits
Here’s
a code snippet that you can use to set version codes for ABI splits.
Give the x86_64 and x86 higher version numbers than ARM, as many x86
devices can run ARM code through an emulation layer, although with
lower performance.
If you don’t wish to manage too many APKs, target the most popular
ones (usually ARM and maybe x86) with a split APK and serve a
universal APK to everyone else.
It’s vital that you publish the universal APK on the Play Store with a lower
version number than all other ABI-specific packages.
If you need more flexibility for your Multi-APK setup, check out
Multi-APK through product
flavors.
Recommended Medium post to choose supported ABIs
In this
post
we will understand what is ABI, problems with the ABI split, and
alternative way to avoid those problems... For instance, Android supports the following ABIs :
mips, mips64, X86, X86–64, arm64-v8a, armeabi, armeabi-v7a
So you have to take a call on supporting 64-bit libraries based on
size vs performance criteria but mips, mips-64, and armeabi should be
removed without any hesitation.
Solve UnsatisfiedLinkError Problem on some devices
As explained here, 64-bit processors generate and check arm64 folder to load native libraries.
If your project does not have arm64 folder. Here is the solution:
build.gradle
defaultConfig {
...
ndk {
abiFilters "armeabi-v7a", "x86"
}
}
You need to add this filters(abiFilters) to your app module’s
build.gradle files. So when your device try to run your app, it will
check gradle file and understands that it should not generate any
folder and use existing native library resources. Boom. Almost solved.
But still there is one more thing. Add this line to your gradle.properties to use deprecated Ndk.
gradle.properties
android.useDeprecatedNdk=true
You can use app bundle so you don't need to handle multiple apks. Google Play will handle it for you automatically. Plus this approach can provide additional benefits. For more details: https://developer.android.com/guide/app-bundle
two weeks ago I uploaded a new version of my Android app to the Developer Console to run an Alpha Test. However I was not able to download this test version on my test device, since the Play Store offered no such update to my test user.
After I was not able to solve this issue here I contacted the Google Developer Support directly.
I now received the following reply:
I’ve looked into your issue and found that your app's Version 15 is not compatible with the Nexus 5 due to a conflict in your app’s manifest with the following native platforms: armeabi, armeabi-v7a.
For more information about platforms, visit our developer site at https://developer.android.com/ndk/guides/abis.html
This is quite confusing. As far as I understand the information on the linked page, the ABI setting is only available/relevant when working with the NDK. However I am working with the latest SDK version in Android Studio 2.1
Is it even possible to set/define the ABI version when working with the SDK?
The App Manifest does not include any settings related the the ABI version.
When I copy the APK manually to my device (Nexus 5 running Android 4.4.4) and install it, it runs without any problem. So, is the APK really not compatible with my device?
EDIT:
Inspired by the the comment by user1056837 I found this page, that describes how to add an NDK block to the build.gradle file:
android {
...
ndk {
// All configurations that can be changed in android.ndk.
...
}
productFlavors {
create("arm") {
ndk {
// You can customize the NDK configurations for each
// productFlavors and buildTypes.
abiFilters.add("armeabi-v7a")
}
}
create("fat") {
// If ndk.abiFilters is not configured, the application
// compile and package all suppported ABI.
}
}
}
Currently my build.gradle file does NOT include any NDK configuration. I am not sure, how I could solve the problem with the Play Store by adding such config.
As far as I understand the information on the linked page, a fat binary will be created of no abiFilters are configured. Is that correct?
Then one of the following should be correct:
My project does contain some native code without my knowledge. In this case a fat binary is created since my build.gradle file does NOT include any NDK configuration.
My project does not contain any hidden native code. In this case the NDK config would not have any effect at all.
Did I miss something here? No matter which case is correct, in both scenarios I do not know what config would solve the problem...
Maybe it is to late, but nevertheless:
I had the same problem. It was in third-party libraries. When my application started to build, the library bitcoinj created a native script in the /lib/x86_64/darwin/libscrypt.dylib folder. I just excluded this folder in the build.gradle file.
packagingOptions {
exclude 'lib/x86_64/darwin/libscrypt.dylib'
}
After that all started work fine. My app support 5900 devices now.
I am using arcgis in my app and it bundles native dependencies that are large in size. I don't want to include the x86 dependency if it means reducing the size of the apk. How do I tell gradle to automatically exclude the x86 native library.
I tried removing it manually during the build. but it shows up again after rebuild.
how do I tell gradle to automatically exclude the x86 native library
Use splits:
android {
// other good stuff here
splits {
abi {
enable true
reset()
include 'armeabi-v7a'
universalApk false
}
}
}
This tells Android to build only an ARMv7 version of your APK. You would need to adjust the include line to list what APKs you want.
However, you may be better served using splits to just build a separate x86 APK file (have include 'x86', 'armeabi-v7a') and ship both, so you better support x86 but still have smaller files.