In recent update Xamarin made it possible to publish android apps straight to the Google play (before you had to generate apk and upload it manually). More info
These are my version numbers. I was at version 10437 when the update came, I made some changes and raised version number to 10438 and tried the new way of publishing. What happened is that my version number became 141510 for some reason and when I tried to do it again it became 207046. After that I set the number to 320000 and started uploading manully again.
I suspect that the reason for this is that I had Multiple supported architectures and xamarin was uploading multiple apks and I was getting some errors about that. Since then I changed supported architectures to armeabi-v7a only.
Question is:
Can I somehow tell google to forget about these screwed up numbers so I can continue with my 10438 (it won't let me now, I get an error that version number must be bigger then the last one)? Also all versions after 10437 are private and this is the current version on beta (image is from beta channel).
Also do I lose mobile devices if I set my supported architecture as armeabi-v7a only?
versionCode vs. versionName:
The versionCode is not shown to the user:
An integer used as an internal version number. This number is used only to determine whether one version is more recent than another, with higher numbers indicating more recent versions. This is not the version number shown to users
Ref: https://developer.android.com/studio/publish/versioning.html
ABI Architecture:
Google does not breakdown the CPU Information/ABI Architectures in a Dashboard like they do for API level or screen resolution. You can get a device breakdown for your app install:
Ref: https://developer.android.com/distribute/googleplay/developer-console.html#app-stats
Assuming your app is not dependent on a 3rd-party NDK library that only supports a subset of all the ABIs, there is no general reason not to support multi-ABIs as you are just pre-limiting your applications available user-based.
Current API and Screen Sizes and Densities Distributions:
Ref: https://developer.android.com/about/dashboards/index.html
Related
The app has used the embedded wear APK distribution model, but since this distribution method is no longer supported since January, the app has been migrated to use a separate Wear APK.
Followed the guides to set the wearAppUnbundled true flag in the mobile APK and set the <uses-feature android:name="android.hardware.type.watch"/> along with <meta-data android:name="com.google.android.wearable.standalone" android:value="false" /> in the Wear APK.
The only question is what app version code to use when uploading the Google Play?
Let's say version 100 is the legacy version with the embedded wear APK. (minsdk 19)
Version 300 is the new mobile APK without the wear APK, this has been uploaded to the Play Store. (minsdk19)
Now, what version code to use for the Wear APK? (minsdk 25)
If it's set to version code 200 then when preparing the release the Play Console accepts it. However, it says that 300 will not be included in this release. And this is what is scary as one might think that the mobile APK will not be visible on the Play Store if it's released as is based on this message.
Should the "Include" option next to the 300 version APK in the "Not Included" section be used to force the Play Console to keep that one active?
Based on the Multi-APK versioning guide:
This scenario might be "shrinking" since the Wear APK is more restricted (due to the min SDK level and the uses-feature declaration).
However, since the Wear APK uses a lower version code, the capable devices should still receive 300 by default? This is what is confusing, as based on this I'd assume that the 300 version should not be affected at all by uploading a more restricted lower code APK.
The most important thing is to have the new mobile APK as is, and it shouldn't disappear from the Play Store.
As it turns out, it's easy to solve this. In this case, the Wear OS APK had to be uploaded with a higher version code, version code 400, for instance. On the release page, the Include button had to be used to include the 300 version (phone APK).
It kind of make sense, but if one is new to Multi-APK release the messaging is not straightforward and if the app has many installs one thinks twice before taking such actions.
(Probably should have uploaded both APKs in the first place when released the new phone APK)
I was trying to run an A/B test using Firebase A/B testing, but just for specific versions of the app. There were no results and no users exposed to the experiment after 5 days of running it.
After that, I tried to run the same A/B test but without a version restrictions and the first results were available the next day.
So I thought that the way I was defining version restrictions was wrong. I tested it in Remote Config, but the Remote Config was returning the correct values when I applied the same version restriction. Here is how I defined the version restriction in both cases:
The app's version names are in the following format X.Y.Z (e.g. 6.51.0, 6.51.1)
Is there something that I am missing? Is the test significantly slower to start if specific versions are being targeted?
This should work. I have tried this many times. Make sure that you're targeting the correct value based on your app configuration. The Version targeting criterion...
For Android app, you should target the "versionName", not the "versionCode".
For iOS app, you should target the "CFBundleShortVersionString", not the "CFBundleVersion".
In addition, you should put the exact number on the console. For example, if the versionName or CFBundleShortVersionString is 1.0.0, then you should put 1.0.0 and not just 1.0.
When I uploaded the latest version of my native Android app to the Play Store, it gave me the following warning at first:
Warning: Deactivation of this APK will result in your app being available for new installs on fewer types of devices
I decided to upload it anyway, as the number of supported devices was the same as before.
I thought this was a bit strange, as I didn't change my "minSdkVersion".
I released this version to only 1 % of the users, which is approximately 1500 users.
I actually don't know if I should be worried, but I have monitored the activity through AppCenter, which we have integrated into the app. And I think the number of users on the new version is suspiciously low. And 0 crashes in Play Store (which could be a good thing though).
Also, the column "Native platforms" in Play Store changed from 5 to 4.
At this moment I have the following in this column: "arm64-v8a, armeabi-v7a, x86, x86_64"
Unfortunately, I can't see the old information about this anymore, as I release another version afterward (a bug fix). But it was something like this I think:
1 differentiating: armeabi + 4 common: differarm64-v8a, armeabi-v7a,
x86, x86_64
Is this relevant to the number of users being able to download the app and should I be worried?
don't worry about that.
Note: Historically the NDK supported 32-bit and 64-bit MIPS, but support was removed in NDK r17.
https://developer.android.com/ndk/guides/abis
"Native platforms" column changed because mips, mips64 removed in NDK r17.
Generally there isn't any MIPS mobile devices around.
don't forget to check "Supported Android devices".
Is it possible Publish 2 apk for different android version?
I using cordova to build to apps and I need to use crosswalk to build when android version below v4.4.
Higher than v4.4 android just use normal build.
Yes, you can publish multiple APKs to the Play Store.
Each APK must be signed with the same key and must use a different version code. The version that supports a higher minimum SDK version must have the higher version code.
By have two different APKs with differed minSdkVersions defined, users will receive whichever version has the highest support API level.
For full documentation regarding this feature, read the Multiple APK Support documentation.
I have uploaded two APK files into the Google Play store. One is a newer version and one is an older version. The newer version is the active one since it has a higher versionName and Code. Now I found some bugs in the newer version and I want to delete it from the Play Store and activate the older version. Google Play won't let me deactivate the newer one and activate the older one again, since it has a lower versionName and code.
The problem is that I'm am not the developer and did not build the app. The developer is in another country and it is difficult to get hold of them.
What can I do to reactivate the older version again? I know one solution would be to change the versionName and Code. I only have the apk file, can I change those details in Eclipse with only the apk file and very little experience in eclipse or developing android apps?
Thank You
You can't rebuild a new version of an apk from the apk itself.
Have the app developer do the following:
Rebuild project in its previous state with higher version number (must be higher than all previously submitted versions)
Resubmit
From Google's Android "Developer Console" page:
Note that rollbacks aren’t supported due to the app versioning
requirements of the Android platform. If you need to rollback,
consider launching a previous APK with a new version number. However,
this practice should be used only as a last resort, as users will lose
access to new features and your old app may not be forward-compatible
with your server changes or data formats, so be sure to run alpha and
beta tests of your updates.
A good strategy is, when creating a build, modify the manifest to build say a version 2.0 = 39 AND again 2.05 = 45 and generate these two apks which will obviously do the same thing.
Later, when build 2.01 = 40 is in production and you find an error, you can jump back to the old version by uploading the 2.05 = 45 you created earlier.
You have 5 opportunities to back track while releasing 40, 41, 42, 43 and 44 to go back to earlier functionality!
Do this for each build and you can always go back to an earlier version which has been pre compiled and built but with a higher version number than currently in production.
You will not be able to change the APK file without having the signing certificate.
You should be able to revert to an older version, assuming you didn't change the level of API support.
Presumably, go to the Dev console, select the APK tab, hit the "Advanced Mode" option, deactivate the current version and hit "Reactivate" for the version you want.