Develop Reference

Playstore Upload error : Google Play 64-bit requirement [duplicate]

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'

Build a Bundle App for Google play 64bits and 32 bits

I'm here with this problem that have me crazy already.
We were uploading APKs with no problem to the store. Suddenly google play changed their rules and now you only can upload APKs with only 64 bits. So we find out which module of our app has 32 bits folders and deleted them. We generated an APK and uploaded it. No problem, no errors, no warnings. BUT now we have a lot of devices that can not download the app, of course. The old ones, and we need them.
So I tried to generate a Bundle to upload, and I did it. But I am having the SAME problem. Here is what I did:
I have an AAR included in the project that was the one with the 32/64 bits problem. So we opened the project of the AAR and deleted the 32 bits folders, generated the AAR again and included again in the project.
Then I generated the BUNDLE and uploaded to the store. No errors, no warnings, no nothing. But the problem that we had before with the apk is still here, old phones can not download the app.
So then I restored the OLD AAR, with re 32 bits folders, and I generated a BUNDLE with this things in Gradle app file:
defaultConfig {
applicationId "ar.com.redlink.vale"
minSdkVersion 16
targetSdkVersion 28
versionCode 80
versionName "3.15.0"
multiDexEnabled true
vectorDrawables.useSupportLibrary = true
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86'
dimension "default"
}
splits {
abi {
include 'armeabi-v7a','arm64-v8a','x86'
}
}
I tried to upload the Bundle to the store and I get the error that mi files have 32 bits things, so I can not upload it.
I don't know what else to do. Maybe I am not understanding this thing right.

How can i find x64 libs for Skobbler library?

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.

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'

Android NDK - multlib support using gradle

My question is directed towards native Android development for 64bit Android systems.
I am looking for a way to configure the support of 32bit compiled native libraries at a 64bit Android system using the gradle build system. The libraries the application should use are only available as 32bit build. It would be very time consuming and error prone to port these libraries to 64bit.
Hence, I want to configure gradle to deploy these prebuilt 32bit binaries and to use a 32bit version of the Android application as well.
The current configuration leads to the following error:
E/AndroidRuntime﹕ FATAL EXCEPTION: main
Process: <application_name>, PID: 2170
java.lang.UnsatisfiedLinkError:
dalvik.system.PathClassLoader
[DexPathList[[zip file "/data/app/<application_name>/base.apk"],
nativeLibraryDirectories=[/vendor/lib64, /system/lib64]]]
enter code here`couldn't find "libmynativelibrary.so"
at java.lang.Runtime.loadLibrary(Runtime.java:366)
It seems as though the PathClassLoader looks in the wrong directories. I checked the provided apk file and it is lacking the libraries. There is no lib folder inside the apk. The build system does not seam to include the 32bit libraries.
Since there is only one prebuild version for armv7 these libraries are in app/src/main/jnilibs folder.
I have to add that this setup works perfectly for any 32bit Android system. I tried it with the emulator and a physical device before.
How should one activate the multiarch 32/64bit support using gradle? Or how is it possible to deploy a 32bit application to a 64bit Android system using Android Studio/gradle?
I searched the web and found one link concerning the topic, but it is referring to the older build system: https://source.android.com/source/64-bit-builds.html. I do not know how to adopt the description to gradle.
I am using Android Studio (Build: 141.1989493, June 6, 2015).
The project/build.gradle is untouched. The app/build.gradle file looks like this:
apply plugin: 'com.android.application'
android {
compileSdkVersion 22
buildToolsVersion "22.0.1"
defaultConfig {
applicationId "<application_name>"
minSdkVersion 1
targetSdkVersion 22
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'),
'proguard-rules.pro'
}
debug {
debuggable true
}
}
productFlavors {
armv7 {
ndk {
abiFilter "armeabi-v7a"
}
}
fat
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
}

The concept of mulilib is only for projects that are part of an Android system build and you shouldn't set the android:multiarch option as you only have 32bit libs since this option is only for apps that are providing both 32 and 64bit libraries to other installed application.
64-bit Android systems support 32-bit applications directly. You only need to properly package your app, with your .so files inside lib/(armeabi-v7a,x86,...) of the APK, as for any Android devices.
At the install time, the libs of the architecture that is preferred by the device will be installed. ie: if there is no x86_64 folder, the x86 libs will be installed / if there is no arm64-v8a folder, the armeabi-v7a libs will be installed, and your app will run in 32-bit mode.
If you don't have anything under lib, that means Android Studio doesn't know about your .so files. By default it will look for them inside jniLibs/(armeabi-v7a,x86,...), hence you should place them there or change sourceSets.main.jniLibs.srcDir to the directory of your choice.

In order to get 32bit application deployment for 64bit Android system one needs to define a armv7 productFlavor and a subfolder inside the jniLibs folder naming the corresponding architecture.
Product flavor definition in app/build.gradle:
android {
productFlavors {
armv7 { ndk { abiFilter "armeabi-v7a" } }
fat
}
}
Native library structure: 
app/src/main/jniLibs/armeabi-v7a