I was trying to upload the apk since 2 days. Every time I upload the apk I get the 64 bit error. I know there are other questions on Stackoverflow asking the same thing. But most of them saying the solution for flutter.
As per the Google Documentation I used APK Analyze and found that there are .so files in my project.
Based on documentation I added ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'. But Still I get the same error.
Please check my build.gradle code.
android {
compileSdkVersion 29
buildToolsVersion '29.0.0'
defaultConfig {
applicationId "com.XXXXX"
minSdkVersion 15
targetSdkVersion 29
versionCode 237
versionName "3.3.20"
multiDexEnabled true
//ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86_64' - not worked
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
}
applicationVariants.all { variant ->
variant.resValue "string", "versionName", variant.versionName
}
lintOptions {
checkReleaseBuilds false
// Or, if you prefer, you can continue to check for errors in release builds,
// but continue the build even when errors are found:
abortOnError false
}
flavorDimensions "default"
buildTypes {
release {
shrinkResources true
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
dexOptions {
jumboMode true
javaMaxHeapSize "4g"
}
productFlavors {
production {
applicationId 'com.XXXXX'
}
staging {
applicationId 'com.XXXXX.staging'
}
}
// Add this block and enable/disable the parameters as follows
bundle {
density {
// Different APKs are generated for devices with different screen densities; true by default.
enableSplit true
}
abi {
// Different APKs are generated for devices with different CPU architectures; true by default.
enableSplit true
}
language {
// This is disabled so that the App Bundle does NOT split the APK for each language.
// We're gonna use the same APK for all languages.
enableSplit false
}
}}
Please help me to solve the issue.
After signed bundle apk creation the .so files are showing same in armeabi-v7a, arm64-v8a, x86, x86_64 folders.
I tried many solution but didn't work. Later I found that there is a RETAINED APK is existing in play console release and which has 32 bit. Then I deactivated it and uploaded the new apk & It worked successfully
If you say you "found that there are .so files" I assume your project is not compiling but only using them. You then need this native libraries for the missing architectures from the NDK project which produced this libraries. It can't be done just by a different config in your project.
No need to add this line ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64' (Remove this line)
please add this code in your build.gradle file
-After Release Apk you got 2 file of apk in your release folder
-now you can use app-arm64-v8a-release.apk for playstore release
-I hope this is useful for you
android {
lintOptions{
....
}
splits {
abi {
enable true
reset()
include 'armeabi-v7a', 'arm64-v8a'
universalApk false
}
}
}
hi friend i got another way for build 32 and 64 bit release app or bundle.
please add this code your build.gradle file
defaultConfig {
applicationId "com.XXXXX"
minSdkVersion 15
targetSdkVersion 29
versionCode 237
versionName "3.3.20"
multiDexEnabled true
ndk {
abiFilters 'arm64-v8a', 'x86_64'
}
}
note: remove below function
splits {
abi {
enable true
reset()
include 'armeabi-v7a', 'arm64-v8a'
universalApk false
}
}
Related
I an android project in native android. I created a module inside my project inside which I am writing my code in flutter based on docs:https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps
build.gradle for my app looks like:
...
defaultConfig {
applicationId "com.something.somethingelse"
minSdkVersion 21
targetSdkVersion 28
versionCode vcode
versionName "1.0." + vcode
multiDexEnabled true
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
dataBinding {
enabled = true
}
buildTypes {
debug {
signingConfig null
ext.enableCrashlytics = false
}
release {
signingConfig null
minifyEnabled true
testProguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), '../android-lib/proguard-rules.pro', '../android-lib/proguard-test-rules.pro'
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), '../android-lib/proguard-rules.pro'
}
}
// Refer to https://developer.android.com/studio/build/configure-apk-splits
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 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 "x86", "x86_64", "arm64-v8a", "armeabi-v7a"
// Specifies that we do not want to generate a universal APK that includes all ABIs.
universalApk false
}
}
// Map for the version code that gives each ABI a value.
def abiCodes = ['x86':1, 'x86_64':2, 'armeabi-v7a':3, 'arm64-v8a':4]
// APKs for the same app that all have the same version information.
android.applicationVariants.all { variant ->
// Assigns a different version code for each output APK.
variant.outputs.each {
output ->
def abiName = output.getFilter(OutputFile.ABI)
output.versionCodeOverride = abiCodes.get(abiName, 0) * 100000 + variant.versionCode
}
}
When I look at APKs generated in the APK analyzer, apks for "x86", "x86_64", "arm64-v8a" contain libflutter.so but apk for "armeabi-v7a" doesn't contain libflutter.so. I am using latest version of flutter i.e. 1.9.1
Due to missing libflutter.so for this apk, application crashes on some of the devices which use "armeabi-v7a". Is there known fix for this issue? How can I go about debugging this issue?
We are trying to upload the 64bit & 32bit build, according to the recent Google policy change.
We have included respective abifilter "ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'" in the Build.gradle.
We were able to generate the build but when we upload the build to Play console for Beta review. It gives a warning saying "Release is not compliant with 64-bit Google Requirement".
We tried all approach, generating 4 builds (x86,x86_64,armeabi-v7a,arm64-v8a), generating two builds or uploading the universal build with all abifilter, it gives the same warning. We tried all possible approaches.
Please help us out in perfect steps of uploading the build to Play store or if we are making any mistake in generating the build please do let us know on that ends also.
Please check the build.gradle code:
{
minSdkVersion 19
applicationId 'com.xxx.xxx'
targetSdkVersion 28
testInstrumentationRunner 'android.support.test.runner.AndroidJUnitRunner'
versionCode 32 // 27-30
versionName '1.2.1'
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
proguardFile 'proguard-android.txt'
}
Also, we tried with another approach given below:
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 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 "x86", "x86_64", "arm64-v8a", "armeabi-v7a"
// Specifies that we do not want to also generate a universal APK that includes all ABIs.
universalApk true
}
}
ext.abiCodes = ["x86": 1, "x86_64": 2, "armeabi-v7a": 3, "arm64-v8a": 4]
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 * 1 + variant.versionCode
}
}
}
After a couple of days of struggle found the working solution here: diego.org
Basically, if you need the 64-bit library you first need to download the correct library from the source site(Respective library site). Check whether you are using the version of the Library whose 64-bit library is available or not.
Then install it to the local maven repository(Basically your Local Maven will be used in generating the 64-bit apk's):
mvn install:install-file -DgroupId= (library group for e.g.org.xwalk) -DartifactId= (library name for e.g.xwalk_core_library) \
-Dversion=(version no for e.g.23.53.589.4-64bit) -Dpackaging=aar \
-Dfile=(file name for e.g.xwalk_core_library-23.53.589.4-64bit.aar) \
-DgeneratePom=true
And update your build gradle so that the repositories point to your local maven repo:
repositories {
mavenLocal()
}
and you compile the correct lib:
compile 'org.xwalk:xwalk_core_library:23.53.589.4' // Use this library for generating "armeabi-v7a" & "x86" build
compile 'org.xwalk:xwalk_core_library:23.53.589.4-64bit' // Use this library for generating "arm64-v8a" & "x86_64" build
Use the gradle Config:
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64' // For your flavor or defaultConfig
Following these steps will generate two builds one with 32bit and another with 64bit, doing these will also help you to avoid errors like "Fully Shadowed apk"
Hope this helps.
Use the Android App Bundle Publishing method to avoid these errors.
Your application will be built for all types of devices by google.
FIRST OF ALL YOU SET Universal APK = False
Follow This Gradle
android {
compileSdkVersion 28
defaultConfig {
applicationId "photo.abc.video"
minSdkVersion 17
targetSdkVersion 28
versionCode 2
versionName "2.0"
multiDexEnabled true
ndk {
moduleName "andengine_shared"
}
}
useLibrary 'org.apache.http.legacy'
sourceSets {
main {
jni.srcDirs = []
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
lintOptions {
checkReleaseBuilds false
abortOnError false
}
splits {
abi {
enable true
reset()
include "armeabi-v7a", "arm64-v8a", "x86", "x86_64"
universalApk false
}
}
}
ext.abiCodes = ['x86':1, 'x86_64':2, 'armeabi-v7a':3, 'arm64-v8a':4]
i fix my proplem it is easy you dont need mvn install:install-file
just go to download page
https://download.01.org/crosswalk/releases/crosswalk/android/maven2/org/xwalk/xwalk_core_library/21.51.546.7/
and download 2 library
1- 32 bit
2- 64 bit
this
xwalk_core_library-21.51.546.7-arm64.aar
and this
xwalk_core_library-21.51.546.7-x86.aar
after download you need to open file use winrar
take the x86 libart out and add to arm64 file
so now we have 2 library on the file 32 bit and 64 bit
now add this library to android stiduo
file - new - new module - jar/aar
add you libary
after that
add your library on your project
in your build gradle
defaultConfig {
minSdkVersion 16
targetSdkVersion 28
versionCode 17
versionName "3.2"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
multiDexEnabled = true
ndk {
abiFilters 'armeabi-v7a', 'arm64-v8a', 'x86' ,'x86_64'
}
that all
apk analyze yes you have 2 library 32 bit and 64 bit now you can Update your application
According to the new Play Store policy * that will take effect in August * I need to ensure that my app provides not only the 32-bit version, but also a 64-bit version, but when I try to generate that version through NDK, I always get the same libs. After trying and trying and trying, I just received an apk without any kind of "lib" folder.
I've tried to set NDK with abiFilters on gradle and got no changes...
defaultConfig {
applicationId "com.myproject.supermidia"
minSdkVersion 17
targetSdkVersion 26
versionCode 20192201
versionName "2.4"
multiDexEnabled true
vectorDrawables.useSupportLibrary = true
}
In order to build for ARM (and the x86 emulator), the splits should look alike this. x86_64 might be a little useless, because the x86_64 emulator is slow and there is no hardware I'd be aware of ...
android {
defaultConfig {
...
externalNativeBuild {
cmake {
arguments "-DANDROID_ARM_NEON=TRUE", "-DANDROID_CPP_FEATURES=rtti exceptions"
}
}
}
externalNativeBuild {
cmake {
path file('src/main/cpp/CMakeLists.txt')
}
}
splits {
abi {
enable true
reset()
include "armeabi-v7a", "arm64-v8a", "x86"
universalApk true
}
}
}
I'm using proguard to reduce my apk size. The debug apk reduce from 90mb to 55mb, but the signed apk is 71mb. Here is my build.gradle code:
apply plugin: 'com.android.application'
android {
signingConfigs {
XXXX {
keyAlias 'xxxx'
keyPassword 'xxxx'
storeFile file('/Users/xxxx.jks')
storePassword 'xxxxxx'
}
}
compileSdkVersion 23
buildToolsVersion "24.0.2"
defaultConfig {
applicationId "com.xxxx"
minSdkVersion 14
targetSdkVersion 22
versionCode 61
versionName "4.1.8.1"
multiDexEnabled true
signingConfig signingConfigs.XXXX
ndk {
abiFilters "armeabi", "armeabi-v7a", "x86", "mips"
}
}
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.XXXX
}
debug {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.XXXX
}
}
productFlavors {
}
dexOptions {
javaMaxHeapSize "4g"
}
packagingOptions {
exclude 'META-INF/LICENSE.txt'
}
}
and
repositories {
mavenLocal()
maven {
name "jcenter"
url "http://jcenter.bintray.com/"
}
}
dependencies {
...
}
Further explaining sosite's answer, it seems that this happens only if comparing a debug apk built via Run or Debug meant for a specific device (even without Instant Run enabled) instead of a debugapk built via Build > Build APK (for any supported device).
Any variant (even debug itself) built via Build APK will include all the resources for that variant. Also, the Run/Debug apk includes pre-dexed classes specific for that single device, while Build APK ones includes only some general pre-dexed classes that the compiler determines safe for all supported devices - the full dexing only occurs in the device itself, when the apk is installed.
I've zipdiff-ed an apk generated via Debug with another via Build APK for the same variant of the same project and published the simplified output for demonstration (also available as html).
When you build your app locally for specific type of phone then Android Studio attach only necessary resource files. When you build release version then you have attached all types of drawables so you app file size can increase drastically.
I suggest you to use jpg in place of png in as many places as you can and compress them of course - often I use tinyPNG website or just Photoshop ;)
I want use "splits" by "abi", but only for release build. Is this possible? I try use ext variable and variable by "def" also which is set to false by default. This variable is set to true in buildTypes for releaseWithLog (and release).
But I don't know how Gradle work, because when I add writeln() with test message to "debug", "releaseWithLog" and "release" and run build, all messages are in output, so this confirms me that variable "splitsEnabled" is set to true though I build for debug - and I expect value "false" for debug (and not using splits for debug therefore).
apply plugin: 'com.android.application'
android {
compileSdkVersion 19
buildToolsVersion '20.0.0'
ext {
splitsEnabled = false
}
defaultConfig {
...
}
buildTypes {
debug {
...
}
releaseWithLog {
...
splitsEnabled = true
}
release.initWith(releaseWithLog)
release {
...
}
}
...
splits {
abi {
println(splitsEnabled)
enable splitsEnabled
reset()
include 'x86', 'armeabi-v7a', 'armeabi'
exclude 'x86_64', 'mips64', 'arm64-v8a', 'mips'
universalApk true
}
}
...
You can solve this easily with a command line argument to Gradle, or the "Script parameters:" field for a Gradle task in Android Studio. I used -P to define 'dbgBld' symbol and used it for debug builds, e.g.:
gradle -PdbgBld installDebug
My build.gradle file has the following splits command:
splits {
abi {
enable !project.hasProperty('dbgBld')
reset()
include 'armeabi', 'armeabi-v7a', 'x86', 'mips'
universalApk true
}
}
Now to build release I use:
gradle assembleRelease
The 'dbgBld' symbol is not defined, so the splits enable field resolves to true and I get 5 APK files. When building for debugging, the -PdbgBld is already saved in my Android Studio configuration and I get only one "fat" APK for debugging, which results in much faster debug builds.
Greg