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.
Related
I have an app that works only in 64 bit configuration.
I've put in the following in the abi filters
splits{
abi {
enable true
reset()
include "x86_64", "arm64-v8a"
universalApk true
}
}
But when I uploaded the app for alpha track I saw this :
How do I make sure my app is not available for download for something other than 64 bit device?
Have you tried to exclude these builds?
"exclude
Specifies a comma-separated list of ABIs that Gradle should not generate separate APKs for. Use exclude if you want to generate APKs for most ABIs, but need to exclude a few ABIs that your app doesn't support."
https://developer.android.com/studio/build/configure-apk-splits
Set universalApk false, it will build one APK for each platform;then just upload the arm64-v8a package (x86_64 is irrelevant).
I am trying to reduce my Android app. It has a differenct packages, a client package which depenend of bunch of other packages. I am analyzing the APK and saw there are so files for different paltforms namely x86 and armeabi-v7a. I dont want x86 currently. I am using splits to restrict the so files for x86 platform with following code in my build.gradle file.
splits {
abi {
enable false
// By default all ABIs are included, so use reset() and include to specify that we only
// want APKs for x86 and x86_64.
// 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 "armeabi-v7a"
// Specifies that we do not want to also generate a universal APK that includes all ABIs.
universalApk false
}
}
But still I could see the x86 files. Can someone help me in what I am doing wrong?
Use abiFilters from NdkOptions to include the native libraries only of certain ABIs.
Example:
android {
// Similar to other properties in the defaultConfig block, you can override
// these properties for each product flavor in your build configuration.
defaultConfig {
ndk {
// Tells Gradle to build outputs for the following ABIs and package
// them into your APK.
abiFilters 'armeabi', 'armeabi-v7a', 'arm64-v8a'
}
}
}
I'm planning to migrate from ABI split to App Bundle feature. Currently I'm using this code:
def versionCodesAbi = ['x86': 1, 'x86_64': 2, 'armeabi-v7a': 3, 'arm64-v8a': 4]
splits {
abi {
enable true
reset()
include "x86", "x86_64", "armeabi-v7a", "arm64-v8a"
// "armeabi", "mips", "mips64" last three not needed and not supported currently
universalApk true
}
}
android.applicationVariants.all { variant ->
variant.outputs.each { output ->
def abi = versionCodesAbi.get(output.getFilter(OutputFile.ABI))
if (abi != null) {
output.versionCodeOverride =
abi * 1000 + variant.versionCode
}
}
}
which gives 4 APKs per ABI (+ universal one). The reason of using this code is to reduce app size, because of PanoWidget (uses NDK) and
renderscriptTargetApi 28
renderscriptSupportModeEnabled true
After removing splits configuration (+4001 to versionCode) and building Bundle I got .aab file, which converted to .apks (using bundletool) contains folder standalones/. Inside I have four "kinds" of APK, for x86, x86_64, armeabi-v7a and arm64-v8a ABIs. Everything looks fine for now.
Now I've noticed that apps code isn't using RenderScript at all, so I think it's redundant to use supportMode and targetApi. I've removed these two lines, tested on devices/emulator, everything works fine. So next I'm producing Bundle and now it doesn't have x86_64 APK version inside .apks archive... Should it be ommitted without RenderScript support? I'm still using VrPanoramaView and it probably have some specific NDK code for every ABI (don't see on GitHub)... Sadly I don't have x86 (32 or 64) device for testing and nom I'm afraid of releasing this Bundle... Am I missing smth, do I even need _64 version?
Edit:
Removing these two options in the build.gradle will remove the native libraries that were used by RenderScript: librsjni.so and libRSSupport.so. These two libraries will be removed for all ABIs.
Since after disabling RenderScript, you still have 3 ABIs, it looks like your app depends on other libraries which make use of native code, but don't provide the libraries for the x86_64 architecture, which is why the x86_64 directory disappears. This probably means that your app never worked properly on x86_64 before since the x86_64 directory would be loaded by the platform but some native libraries would be missing.
Eventually, you should identify which library brings these native libraries and see if they can also build the 64 bit version, but in the short term, nothing will break since the x86_64 devices also support x86 (32-bit) libraries.
Previous post:
If you have any *.bc files in your APK, the 64-bit libraries are removed from the APKs because those RenderScript files are 32-bit only and cannot be loaded in a 64-bit process.
If you migrate to a more recent version of RenderScript, the *.bc files won't be generated and the 64-bit native libraries will be present again in the APKs. Or if you don't need RenderScript at all, then remove those files completely.
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
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.