Develop Reference

Not able to Upload 64-bit build in Google play Store

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

after split APK which one should I choose?

I split my apk application and I got multiple apk
now which one I will choose to import to my play store ?

You add all of them, Play Store chooses the right one for the user, depending on their device. Just be sure to use different version codes for every apk.
See official documentation for more information.

you can let gradle auto configure your version code, then upload ALL of the apps to the play store.
google's example below will auto append 001, 002 or 003 depending on the variant ('armeabi-v7a':1, x86:2, x86_64:3).
do note that you will have to upload the play store from the smallest number to the biggest number.
see https://developer.android.com/studio/build/configure-apk-splits.html#configure-APK-versions
android {
...
defaultConfig {
...
versionCode 4
}
splits {
...
}
}
// 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
}
}
}
For more examples of alternate version code schemes, see Assigning version codes (https://developer.android.com/google/play/publishing/multiple-apks.html#VersionCodes)

Yeah, It depends on which device you want to target. For more information Below - stackoverflow and developer's official links are also be helpful to you:
Publish Multiple APKs to Google Play Store
https://developer.android.com/studio/build/configure-apk-splits.html#build-apks

Depends on which device you want to target. Play store will tell you how much device you have left out after uploading an apk. Make sure you have version code different for each flavor if you want to upload multiple ones. For example,I have XXXn where n is the code for cpu architecture.

I can't publish multiple release
the problem is the release code or version
ext.abiCodes = ['x86_64':1,'x86':2,'armeabi':3,'armeabi-v7a':4,'arm64-v8a':5,'mips':6]
android {
compileSdkVersion 27
defaultConfig {
applicationId "com.book.walid.resumephilosophie"
minSdkVersion 15
resConfigs "ar"
targetSdkVersion 27
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
splits {
abi{
enable true
reset()
include 'x86_64','x86','armeabi','armeabi-v7a','arm64-v8a','mips'
universalApk false
}
}
android.applicationVariants.all { variant ->
def baseAbiVersionCode =
project.ext.abiCodes.get(com.android.build.OutputFile.ABI)
if (baseAbiVersionCode != null) {
output.versionCodeOverride =
baseAbiVersionCode * 1000 + variant.versionCode
}
}
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}

Android Studio 3.0 Flavor Dimension Issue

Upgraded to Studio Canary build. My previous project of Telegram Messenger is giving following error.
Error:All flavors must now belong to a named flavor dimension. The flavor 'armv7' is not assigned to a flavor dimension. Learn more at https://d.android.com/r/tools/flavorDimensions-missing-error-message.html
What should I do? I have already seen that link but couldn't understand what to do. I have 3 build variants now, release,debug and foss.

If you don't really need the mechanism, just specify a random flavor dimension in your build.gradle or build.gradle.kts:
android {
...
flavorDimensions("default")
...
}
For more information, check the migration guide

After trying and reading carefully, I solved it myself.
Solution is to add the following line in build.gradle.
flavorDimensions "versionCode"
android {
compileSdkVersion 24
.....
flavorDimensions "versionCode"
}

Here you can resolve this issue, you need to add flavorDimension with productFlavors's name and need to define dimension as well, see below example and for more information see here https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html
flavorDimensions 'yourAppName' //here defined dimensions
productFlavors {
production {
dimension 'yourAppName' //you just need to add this line
//here you no need to write applicationIdSuffix because by default it will point to your app package which is also available inside manifest.xml file.
}
staging {
dimension 'yourAppName' //added here also
applicationIdSuffix ".staging"//(.staging) will be added after your default package name.
//or you can also use applicationId="your_package_name.staging" instead of applicationIdSuffix but remember if you are using applicationId then You have to mention full package name.
//versionNameSuffix "-staging"
}
develop {
dimension 'yourAppName' //add here too
applicationIdSuffix ".develop"
//versionNameSuffix "-develop"
}

If you want not to use dimensions you should use this line
android {
compileSdkVersion 24
...
flavorDimensions "default"
...
}
but if you want ti use dimensions you should declare your dimension name first and then use this name after
THIS example is from the documentations:
android {
...
buildTypes {
debug {...}
release {...}
}
// Specifies the flavor dimensions you want to use. The order in which you
// list each dimension determines its priority, from highest to lowest,
// when Gradle merges variant sources and configurations. You must assign
// each product flavor you configure to one of the flavor dimensions.
flavorDimensions "api", "mode"
productFlavors {
demo {
// Assigns this product flavor to the "mode" flavor dimension.
dimension "mode"
...
}
full {
dimension "mode"
...
}
// Configurations in the "api" product flavors override those in "mode"
// flavors and the defaultConfig block. Gradle determines the priority
// between flavor dimensions based on the order in which they appear next
// to the flavorDimensions property above--the first dimension has a higher
// priority than the second, and so on.
minApi24 {
dimension "api"
minSdkVersion 24
// To ensure the target device receives the version of the app with
// the highest compatible API level, assign version codes in increasing
// value with API level. To learn more about assigning version codes to
// support app updates and uploading to Google Play, read Multiple APK Support
versionCode 30000 + android.defaultConfig.versionCode
versionNameSuffix "-minApi24"
...
}
minApi23 {
dimension "api"
minSdkVersion 23
versionCode 20000 + android.defaultConfig.versionCode
versionNameSuffix "-minApi23"
...
}
minApi21 {
dimension "api"
minSdkVersion 21
versionCode 10000 + android.defaultConfig.versionCode
versionNameSuffix "-minApi21"
...
}
}
}
...

I have used flavorDimensions for my application in build.gradle (Module: app)
flavorDimensions "tier"
productFlavors {
production {
flavorDimensions "tier"
//manifestPlaceholders = [appName: APP_NAME]
//signingConfig signingConfigs.config
}
staging {
flavorDimensions "tier"
//manifestPlaceholders = [appName: APP_NAME_STAGING]
//applicationIdSuffix ".staging"
//versionNameSuffix "-staging"
//signingConfig signingConfigs.config
}
}
Check this link for more info
// Specifies two flavor dimensions.
flavorDimensions "tier", "minApi"
productFlavors {
free {
// Assigns this product flavor to the "tier" flavor dimension. Specifying
// this property is optional if you are using only one dimension.
dimension "tier"
...
}
paid {
dimension "tier"
...
}
minApi23 {
dimension "minApi"
...
}
minApi18 {
dimension "minApi"
...
}
}

in KotlinDSL you can use like this :
flavorDimensions ("PlaceApp")
productFlavors {
create("tapsi") {
setDimension("PlaceApp")
buildConfigField("String", "API_BASE_URL", "https://xxx/x/x/")
}
}

If you have simple flavors (free/pro, demo/full etc.) then add to build.gradle file:
android {
...
flavorDimensions "version"
productFlavors {
free{
dimension "version"
...
}
pro{
dimension "version"
...
}
}
By dimensions you can create "flavors in flavors". Read more.

Android Studio split APK over Density

splits {
// Configures multiple APKs based on screen density.
density {
// Configures multiple APKs based on screen density.
enable true
reset()
// Specifies a list of screen densities Gradle should create multiple APKs for.
include 'ldpi', 'mdpi', 'hdpi', 'xhdpi', 'xxhdpi', 'xxxhdpi'
// Specifies a list of compatible screen size settings for the manifest.
//compatibleScreens 'small', 'normal', 'large', 'xlarge'
}
// Configures multiple APKs based on ABI.
abi {
// Enables building multiple APKs per ABI.
enable false
// By default all ABIs are included, so use reset() and include to specify that we only
// want APKs for x86, armeabi-v7a, and mips.
// 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', 'arm64-v8a', 'x86', 'x86_64'
// Specifies that we do want to also generate a universal APK that includes all ABIs.
universalApk true //generate an additional APK that contains all the ABIs
//'armeabi' - Not surported by Realm since v2.0.0
}
}
I'm trying to split my APKs by Desity in order to reduce APK size, using the above Gradle it splits the APKs into densities but the drawable resources for each APK are identical.
Should the result of this not be that the xhdpi APK only contains only drawable-ldrtl-xhdpi-v17, drawable-xhdpi-v4 and mipmap-xhdpi-v4?

Example of density apk split in gradle:
apply plugin: 'com.android.application'
android {
compileSdkVersion 19
buildToolsVersion = rootProject.ext.buildToolsVersion
defaultConfig {
versionCode 12
minSdkVersion 16
targetSdkVersion 20
buildConfigField "String", "FOO", "\"bar\""
}
splits {
density {
enable true
exclude "ldpi", "tvdpi", "xxxhdpi", "400dpi", "560dpi"
compatibleScreens 'small', 'normal', 'large', 'xlarge'
}
}
}
// map for the version code
ext.versionCodes = [all:1, mdpi:2, hdpi:3, xhdpi:4, xxhdpi:5]
android.applicationVariants.all { variant ->
// assign different version code for each output
variant.outputs.each { output ->
def key = output.getFilter(OutputFile.DENSITY) == null ? "all" : output.getFilter(OutputFile.DENSITY)
output.versionCodeOverride = project.ext.versionCodes.get(key) * 100 + android.defaultConfig.versionCode
}
}

Remove x86_64 package from Realm

I'm working with AS and I don't need the x86_64 package in realm. The x86_64 package cause some problems with other libs. How to remove the package?

abiFilters will be a good solution. The method will limit the abi and only add the specified abi when building the apk.
defaultConfig {
applicationId "com.example.app"
minSdkVersion 16
targetSdkVersion 24
versionCode 1
versionName "1.0"
ndk {
abiFilters "armeabi", "armeabi-v7a", "x86"
}
// ...
}
This means only those specified arch-folders will be used and the rest can be deleted.

Well, you can remove any of the architecture folders, but keep in mind, that means the library in question (this case it's realm) will not work on those architectures that you remove.
To be frank, you can just simply remove it, but as I mentioned above, that is no good.
You can include/exclude different architectures from your build by a technique called splitting:
android {
// Rest of Gradle file
splits {
abi {
enable true
reset()
include 'armeabi', 'armeabi-v7a', 'arm64_v8a', 'mips', 'x86'
universalApk true
}
}
}
//Ensures architecture specific APKs have a higher version code
//(otherwise an x86 build would end up using the arm build, which x86 devices can run)
ext.versionCodes = [armeabi:1, 'armeabi-v7a':2, 'arm64-v8a':3, 'mips':4, x86:5]
android.applicationVariants.all { variant ->
// assign different version code for each output
variant.outputs.each { output ->
int abiVersionCode = project.ext.versionCodes.get(output.getFilter(OutputFile.ABI)) ?: 0
output.versionCodeOverride = (abiVersionCode * 10000) + android.defaultConfig.versionCode
}
}