Android testers not receiving application update - android

I have published multiple apk android aplication. First apk is with versionCode 10106 and second apk with version 14106.
Now, i have updated application and made changes so that i dont have two apk files, but one single apk for all API's. VersionCode of new apk is 19112.
Application is published to Alpha section. None of my testers received update yet. Three days passed. I have received update 2hrs after publish, so i do not think is GooglePlay store fault.
I am using Nexus5 with Android L developer preview installed. And i am sure that some of my testers have 4.4.4 KitKat on ther phones, but again it does not make sense, because it says that there are 6324 supported devices.
Below you can see my build.gradle file.
apply plugin: 'android'
android {
compileSdkVersion 19
buildToolsVersion '19.1.0'
defaultConfig {
applicationId "com.example"
minSdkVersion 10
targetSdkVersion 19
versionCode 19112
versionName '1.1.2'
}
buildTypes {
release {
runProguard true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard- project.txt'
}
}
}
dependencies {
compile 'com.android.support:support-v4:19.+'
compile 'com.google.android.gms:play-services:+'
compile 'com.android.support:appcompat-v7:19.+'
}
This is a warning i have on PlayStore:
A device with API levels in range 14+ is eligible to receive version 14106, which is optimized for higher API levels, but actually receives version 19112 because it has a higher version code. This would occur when
Release track containing any of [BETA] and
Screen layouts containing any of [small, normal, large, xlarge] and
OpenGL ES versions in range 2.0+ and
Features containing all of [android.hardware.screen.LANDSCAPE, android.hardware.TOUCHSCREEN].
A device upgrading from API levels in range 10-13 to API levels in range 14+ would become eligible to receive version 14106, which is optimized for higher API levels, but would actually receive version 19112 because it has a higher version code. This would occur when
Release track containing any of [BETA] and
Screen layouts containing any of [small, normal, large, xlarge] and
OpenGL ES versions in range 2.0+ and
Features containing all of [android.hardware.screen.LANDSCAPE, android.hardware.TOUCHSCREEN].
Some devices are eligible to run multiple APKs. In such a scenario, the device will receive the APK with the higher version code.
Previously active APKs supported more devices than those in the draft configuration.
Some devices will not receive upgrades.
Devices currently running version 8100 are no longer supported by the current configuration. Such devices will not receive upgrades.
API levels in range 8-9 and
Release track containing any of [ALPHA, BETA] and
Screen layouts containing any of [small, normal, large, xlarge] and
OpenGL ES versions in range 2.0+ and
Features containing all of [android.hardware.LOCATION, android.hardware.location.GPS, android.hardware.screen.LANDSCAPE, android.hardware.TELEPHONY, android.hardware.TOUCHSCREEN]

Related

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.

Why are my supported android devices so low?

Why are my supported android devices so low? I've tried to target the lowest possible apk (13), and yet only 12,000 devices can use my app.
Any help would be much appreciated!
Here is my build.gradle.
android {
signingConfigs {
}
compileSdkVersion 23
buildToolsVersion '25.0.0'
defaultConfig {
applicationId "thomas.surfaceviewtest"
minSdkVersion 13
targetSdkVersion 13
versionCode 5
versionName "1.0.5"
multiDexEnabled true
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
}
}
dexOptions {
}
}
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile 'com.android.support:appcompat-v7:23.4.0'
compile 'com.android.support:design:23.4.0'
compile 'com.google.android.gms:play-services-ads:9.4.0'
compile 'com.google.firebase:firebase-ads:9.4.0'
}
apply plugin: 'com.google.gms.google-services'
That number is comparting your manifest configuration and a list of devices know by Google (see the list of devices).
It is not a number of real devices, but a number of model supported, so 12000 models on the market is a good number I believe.
Its because your target sdk level is low
targetSdkVersion 13
Update it to 25 so it will support more devices
targetSdkVersion 25
You can check for more android sdk version here
My app is compatible with 12611 devices. That is basically the same as you have. 12000 devices isn't little, especially given the fact that there are "only" 1465 unsupported devices as a result of my minSdk version being high.
Targeting 12k devices isn't little, it is a lot. If you were only targeting say 8k that would be something you should look into.
You should still change compile and minSdk versions to 25 or 26 (7.1 or 8.0) to make sure your app can run the newest API's.
I'd like to clarify the fact that targeting API 13 doesn't exclude API 14-26 from installing the app. It indicates what version it is designed for. You compile against 23 so you have the new API's included, but you only use API 13.
This should help:
android:targetSdkVersion
An integer designating the API Level that the application targets. If not set, the default value equals that given to minSdkVersion.
This attribute informs the system that you have tested against the target version and the system should not enable any compatibility behaviors to maintain your app's forward-compatibility with the target version. The application is still able to run on older versions (down to minSdkVersion).
As Android evolves with each new version, some behaviors and even appearances might change. However, if the API level of the platform is higher than the version declared by your app's targetSdkVersion, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect. You can disable such compatibility behaviors by specifying targetSdkVersion to match the API level of the platform on which it's running. For example, setting this value to "11" or higher allows the system to apply a new default theme (Holo) to your app when running on Android 3.0 or higher and also disables screen compatibility mode when running on larger screens (because support for API level 11 implicitly supports larger screens).
Source: https://developer.android.com/guide/topics/manifest/uses-sdk-element.html
You should your increase target sdk level.
targetSdkVersion 25

Playstore "This configuration cannot be published"

I am trying to update my apk in the play store but I am getting the following error :
This configuration cannot be published for the following reason(s):
·It is forbidden to downgrade devices which previously matched version 13 to version 1, which would occur when API levels in range 14+ and
Release track containing any of [ALPHA] and
Screen layouts containing any of [small, normal, large, xlarge] and
OpenGL ES versions in range 2.0+ and
Features containing all of [android.hardware.LOCATION, android.hardware.location.GPS, android.hardware.location.NETWORK, android.hardware.screen.PORTRAIT, android.hardware.TELEPHONY, android.hardware.TOUCHSCREEN].
·It is forbidden to downgrade devices which previously used M permissions (target SDK 23 and above) to APKs which use old style permissions (target SDK 22 and below). This occurs in the change from version 13 (target SDK 23) to version 1 (target SDK 21).
·Some devices are eligible to run multiple APKs. In such a scenario, the device will receive the APK with the higher version code.
build.gradle:
defaultConfig {
applicationId "my.project"
minSdkVersion 14
targetSdkVersion 23
versionCode 14
versionName "2.3"
}
Previous Version was :
versionCode 13
versionName "2.2"
Does the usage of third party libraries affect this. A newer version of 3rd party library was included into the project after several releases of the app.

Deploying multiple APK with vector asset (android)

android studio is currently supporting vector assets. according to the literature I can
Create separate APKs for different API levels. When you don’t include
the corresponding raster images in the APK for Android 5.0 (API level
21) and higher, the APK can be much smaller in size. For more
information, see Multiple APK Support.
so I tried creating 2 APIs: -
the pre-lollipop version contains the generated pngs without the vector assets,
while the lollipop version contains only the vectors assets
In http://developer.android.com/google/play/publishing/multiple-apks.html
If an APK you've uploaded for API levels 4 and above (Android 1.6+) has a version code of 0400, then an APK for API levels 8 and above (Android 2.2+) must be 0401 or greater. In this case, the API level is the only supported filter used, so the version codes must increase in correlation with the API level support for each APK, so that users get an update when they receive a system update.
The following is my gradle build file.
compileSdkVersion 23
buildToolsVersion "23.0.2"
defaultConfig {
applicationId "twitch.angelandroidapps.matchit"
}
productFlavors {
lollipopConfig {
minSdkVersion 21
targetSdkVersion 23
versionCode 3
versionName "21.1.0"
}
preLollipopConfig {
minSdkVersion 10
maxSdkVersion 20
targetSdkVersion 17
versionCode 2
versionName "10.1.0"
}
}
:
//snipped the rest of the build config...
:
however, when I deploy the pre-lollipop version first, followed by the lollipop version, then the pre-lollipop version got archived (and vice-versa).
Any advice on how I can get both versions to be deployed in the play store?
I had it figured out.
When i first deploy the lollipops and pre-lollipops, they get auto-archived.
For some strange reason, I have to manually shift the pre-lollipop version back into production by clicking "Move to Prod" for it to work.
After that, the playstore will show a new "API LEVELS" column.
Also the literature about having a larger versionCode seems to be wrong. Pre-lollipop version needs to always be a lower VersionCode (probably because my API levels do not overlap?). Anyway, I can now deploy new pre-lollipop versions without getting the previous version archived.
In the end, I used the naming convention of
21xxxx for lollipop versions and
10xxxx for pre-lollipop versions
Hope it helps.

Android: "configuration cannot be published" while Uploading APK to Play Store

Need help with an Android Play Store issue I've seen while trying to update our app.
The problem appears when the apk upload is done, and the following message shows up:
This configuration cannot be published for the following reason(s):
It is forbidden that a device upgrading from API levels in range 14-18 to API levels in range 19+ should downgrade from version 10 to version 9, which would occur when
Screen layouts containing any of [small, normal, large, xlarge] and
Features containing all of [android.hardware.LOCATION, android.hardware.location.GPS, android.hardware.screen.PORTRAIT, android.hardware.TOUCHSCREEN, android.hardware.WIFI].
Some devices are eligible to run multiple APKs. In such a scenario, the device will receive the APK with the higher version code.
What is somewhat strange is that the Play Store lists our supported API levels as 14-18, whereas our SDK settings are as follows:
/* build.gradle */
...
android {
compileSdkVersion 21
buildToolsVersion "21.1.2"
defaultConfig {
applicationId "<my app id>"
minSdkVersion 14
targetSdkVersion 21
}
...
/* AndroidManifest.xml */
...
android:versionCode="10"
android:versionName="1.1.1" >
<uses-sdk
android:minSdkVersion="14"
android:targetSdkVersion="21" />
...
Another (perhaps minor) issue is that the following permission is listed under the APK DETAILS tab of the Play Store despite that we don't set this in our manifest file:
android.permission.CHANGE_WIFI_STATE
When we switch the build/target SDK version to 19 (as we previously did), Android Studio correctly complains that we are not using the latest Android version. Even then, we still see the upload problem.
Might there be something else in our configuration that is wrong?
Thanks in advance for your assistance!
OK, I finally managed to solve the issue.
Used aapt to see how Play Store would parse the apk
Found out that an external, closed-source library that I'm using sets a maxSdkVersion=18 in its manifest library
Obtained a version of the offending library that doesn't have the max SDK setting.
Recompiled the app and successfully uploaded to the play store.
An alternative to step 3 would have been to override the maxSdkVersion in my main AndroidManifest.xml file, or Disable Manifest Merger in Android Gradle Build in gradle, but Android Studio wasn't very cooperative on that front.
Admittedly, the error message on Play Store is rather cryptic and could be worded better.

Categories

Resources