Develop Reference

How to convert multiple apk files into a unified bundle

My Android app uses a custom native library (written in C++) that I compile for each of the architectures armeabi-v7a, arm64-v8a, x86 and x86_64. The earliest version of Android that supports 64-bit native libraries (arm64-v8a / x86_64) is API level 21 but with the 32-bit native libraries (armeabi-v7a / x86) I'm able to support devices down to Android API level 16.
Due to those differing API levels and because the compiled libraries get quite big I create a specific apk file for each of those architectures. So, eventually I have 4 different apk files which enables my app to run on pretty much every Android device down to API level 16. That approach works and is documented here. My build.gradle file that builds those apk files looks as follows:
android
{
...
defaultConfig
{
minSdkVersion 16
targetSdkVersion 29
...
}
flavorDimensions "abi"
productFlavors
{
"ARM7"
{
dimension "abi"
ndk.abiFilters 'armeabi-v7a'
versionCode 160000 + android.defaultConfig.versionCode
versionNameSuffix "-arm32"
}
"ARM8"
{
dimension "abi"
ndk.abiFilters 'arm64-v8a'
minSdkVersion 21
versionCode 210000 + android.defaultConfig.versionCode
versionNameSuffix "-arm64"
}
"x86"
{
dimension "abi"
ndk.abiFilters 'x86'
versionCode 160000 + android.defaultConfig.versionCode
versionNameSuffix "-x86"
}
"x86-64"
{
dimension "abi"
ndk.abiFilters 'x86_64'
minSdkVersion 21
versionCode 210000 + android.defaultConfig.versionCode
versionNameSuffix "-x64"
}
}
...
}
Now, Google pushes the new Android Bundle format and the documentation currently states
Important: In the second half of 2021, new apps will be required to publish with the Android App Bundle on Google Play. New apps larger than 150 MB must use either Play Feature Delivery or Play Asset Delivery.
So, at some point I will have to convert my multi-apk approach to that new Android Bundle format but I'm essentially clueless how this is supposed to work. While each of my apk file contains its own manifest with its own version number and minSdkVersion an Android Bundle contains one unified manifest.
How would I be able to create an Android Bundle that eventually has the same effect as my 4 existing apk files?

First of all, there is an easier way of achieving what you already have- splits-on-abi (see https://developer.android.com/studio/build/configure-apk-splits). This method handles the versionCode and so forth for you.
As noted on that page- it's better to use app bundles for this purpose now. App bundles have two main purposes- to minify(/optimize) downloads, and to allow for dynamic modules. The first bit makes it so that Google Play essentially takes your huge app-bundle containing everything, and makes a smaller apk containing only what is needed for the particular device that is asking. It is only this minimal apk that is downloaded to the device.
So, to summarize: You upload one big app bundle to Google Play containing everything for all devices. Google Play then builds minimal apks containing only what is needed, and downloads only those to device. Technically speaking, Google play creates an .apks which is downloaded, this is essentially a zip file with multiple .apk files, following this format: but that is mostly just an implementation detail you don't need to worry about.
You can simulate and try out how app bundles work (.aab format) with the bundletool (https://github.com/google/bundletool/releases) which according to Google is what Google Play is using to handle app bundle files.
Also, you can drop the flavors. Those will only get in the way now.

Impossible to create APK with 64 bits lib under Android Studio

I need to update an existing app on the Play Store. For this reason, since August, Google has requested to provide 64-bit versions as well.
I have included the instructions provided in the build.gradle app as follows:
compileSdkVersion 28
defaultConfig {
applicationId "com..."
minSdkVersion 24
targetSdkVersion 28
versionCode 10
versionName "1.5"
multiDexEnabled true
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
ndk {
abiFilters 'arm64-v8a','x86_64','armeabi-v7a','x86'
}
}
and:
splits {
abi {
enable true
reset()
include 'arm64-v8a','x86_64','armeabi-v7a','x86'
universalApk true
}
}
I am able to generate the APK as expected, but unfortunately both arm64-v8a and x86_64 versions do not contain any 64-bit code.
There is no lib directory when analyzing the APK in Android Studio while the APK armeabi-v7a includes lib / libarm_arch.so.
Note no error message is shown by the compilation process.
Can a dependency cause this problem and why can't Android Studio show an error message?
How can I identify why the 64-bit version is not generated?
I'm using Android Studio for 3.5.
After searching about the libarm_arch.so library, I have found that it's linked to FFMPEG. But FFMPEG is not referenced in my Gradle dependencies and I have not still found how to tell to Android Studio to embed the arm68-v8a version of the library as well.
Thanks for your help.

I had the same problem, I've converted a project of 2 years ago to latest Android Studio, now I need to generate the 64bit, but APK built and Bundle do not generate 64 bit output.
I found out I had a directory which was causing this incompatibility:
app/src/main/jniLibs (this one had /armeabi /armeabi-v7a /x86 subdirs in it)
I fixed it by deleting the directory jniLibs.

How can I identify why the 64-bit version is not generated?
from https://developer.android.com/distribute/best-practices/develop/64-bit#64-bit-libraries
In a typical case, an APK or bundle that's built for both 32-bit and 64-bit architectures will have folders for both ABIs, each with a corresponding set of native libraries. If there's no support for 64-bit, you'll likely see a 32-bit ABI folder but *not a 64-bit folder*.
Edit:
if your read just one the same link
https://developer.android.com/distribute/best-practices/develop/64-bit#port-32-to-64
you will confirm if you are really making any change on your code to be able to port 32 to 64
you could be doing the right step on the gradle , but not in the code.
i can't say anything more if you don't provide a sample
Android Studio don't have anything to complains if you keep your code on 32 and try to build to 64, it just keep your 64 folder build result empty as a point on my first response
I hope that helps :)

Android ABI split migrating to App Bundle

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.

How to make Android apps which support both 32-bit and 64-bit architecture?

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'

How to import only selected native library ABIs from AAR?

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.