I have a published app in google play. Is it possible to publish an app update, that will affects only the new users? So the existing users will not be able to update.
Thanks!
If by "new users" you mean the normal public that did not install your app yet, then no. That is not possible. Once you publish your app, anybody will be able to access the new version.
You could potentially publish it under a different app-id as a brand new app that just happens to be an almost exact copy of your old app, then there will be no update path from one to the other, but there is no way that "new users" wouldn't find your original app first, or that old users wonder what that weird new clone app is.
If you want an app that is only available to a specific set of people for testing, or create different apps for experimenting, you can read up on it here: https://support.google.com/googleplay/android-developer/answer/12053285
Actually it is possible and is related to versionCode.
Basically, if you upload an app with versionCode lower than already installed by your users, they will not be able to update, just new user will.
Google explain some use cases where it would be used:
In some specific situations, you might wish to upload a version of
your app with a lower versionCode than the most recent version. For
example, if you are publishing multiple APKs, you might have pre-set
versionCode ranges for specific APKs. For more about assigning
versionCode values for multiple APKs, see Multiple APK Support.
Related
I am setting up different app flavors for my Android app in order to generate different app versions for different app stores.
Now, I am wondering whether I should better use the same applicationId for all stores, or whether I should always use a new applicationId for a new store?
Will I run into any pitfalls when using the same applicationId for all stores?
I'd suggest you to use the same applicationId. Otherwise users would be able to install multiple versions of your app.
This is from the android documentation about the appliation id:
Every Android app has a unique application ID that looks like a Java package name, such as com.example.myapp. This ID uniquely identifies your app on the device and in Google Play Store.
Some more research led me to the conclusion that using the same applicationId (as proposed by oemel09) is the best option (at least in my case).
That way, the app can't be installed twice on the same phone. (Two apps with the same applicationId can't be installed on one phone.)
However, an app installed from Store X can then be updated with another version of Store Y. This can lead to problems if the app version from Store X is slightly different to the one form Store Y.
Using different certificates (app signing) for the two app stores solves this problem. Different certificates won't allow one store to overwrite the app version of another store.
(In case you, like me, activated App signing by Google Play you won't be able to use the same certificate anyway.)
I have 2 apps published but I don't know how to manage the life cycle of the application. For example if I have a bug, the way I do it now: once I have a correction for the bug I go into studio->file->project structure->flavors, I increment the version code, then build the APK. Then I go into GPC->APK menu,upload new APK to prod.
I think this is not the right way to do. It obliges the user to un-install and re-install.
How do I manage updates?
How do I manage patches?
Sorry about the dumb questions. I've searched for docs but struggle to find it.
No, you are doing it correctly.
Whenever you fix any bug or add a new feature and feel that your app is ready to be updated in Play Store, you need to increment your versionCode and versionName.
Now, you need to open Google Play Console and upload the new APK. Incrementing the versionCode is mandatory for Google Play to consider it as an update.
Don't worry, the users will not need to uninstall the old app and reinstall the new app manually. Everything is handled seamlessly by the Google Play app installed on the user's device.
And the users also don't download the entire app after every update. Google now uses File-by-File patching to reduce the app update size drastically. So, in simple words, the users only download the changed and they get patched automatically.
EDIT
You need to increment the versionCode for the updates to happen. The versionName is only shown to the user so that they can understand that it is an update over the previous version. The versionCode is used for internal purposes and is not shown to the user.
Ex - If your versionCode is 10, you can increment it to 11 for an update to happen, even if the versionName is not changed at all. But it is RECOMMENDED to change the versionName in accordance with the versionCode so that your users can understand that you have updated the app.
im very new to the google play and mobile app world.
I would like to know the process of updating my app on the google play store as im not sure how. It is Android app.
I am using xamarin for the app. I have increased the version name to by .1 and if I do this, do I have to also increase the version number to 2 ? because it cannot take decimal points.
I have a simple understanding of It so im not sure if I have to create a new apk or update the existing one, and if so, how ?
and then on google play, do I just go and select the new apk, or updated apk ?
Thanks in advance
The version number (or version code) it's an integer value used to determine whether one version is more recent than another. This is not shown to the end users. Every new version you make should have a higher number than the previous. You can simply increase the number by one each time a new version is released.
The version name is a string, and it's only meant to be shown to users. It can be whatever you want, like "1.0" or "Beta 1.2.3".
To update an app you just upload a new apk to Google Play, and the system uses its version number to find out what's the newest apk ank make it visible by default.
There is a very good, detailed, step-by-step process at http://developer.xamarin.com/guides/android/deployment,_testing,_and_metrics/publishing_an_application/ (which also explains the difference between version # and version name, among other things). Definitely worth a read!
No previous questions about it, so here I ask.
Background:
I have an old app, in free and paid versions, in the Play Market. I created a new version, radically changed and with a different payment system (free app + in app purchases only, no more a paid version: reduce maintenance costs). minSdkVersion also changed from 1.5 to 2.1.
Because of all those differences, I decided to upload a new app, not just update the current one (i.e., not selectively provide a new apk for API 7+ --- multiple APKs). This is especially important because of the new payment system, as I don't want to force old, paid customers, to buy everything again. I want to leave them alone and happy as they are (4.4/4.7 rating). In short, I don't want to "force" people into anything. In this case, into buying again the same thing through in-app-purchases, besides other things the new app offers.
Questions:
Having explained to you my background, it raises the obvious questions:
1. How do I hide the old apps from the API 7+ audience while still keeping them visible to all the current API 7+ customers, i.e., those that already bought it?
My biggest concern here is the paid app. I'm thinking about pushing a new version with maxSdkVersion set to 6 (SDK 2.0.1), effectively blocking new API 7+ customers to the old apps. But I'm worried that the current API 7+ customers will suddenly lose access to the app. That raises two questions:
2. Will they be able to keep updating the app? is it reasonable to guess "yes"?
3. Even if the answer to the previous question is "yes", it's still unclear to me what will happen if the user uninstalls the app, and then go find it again in the Market (not just updating). Will it disappear or will it still appear under his "bought" apps list, considering that meanwhile the app filter requirements changed?
Remark: I would upload a test app to see that, but AFAIK the author is not allowed to buy his own app (even the license behaves differently), so I couldn't test the uninstall-filter-install scenario.
# # # # # # # Reply to answers: # # # # # # #
#Sparky:
I think you got it wrong. I know my way around multiple APKs, and, of course, the documentation. The problematic here is way beyond that.
Note also that maxSdkVersion is deprecated, so this throws a little bit of a wrench into your proposal to cap the old APK when you issue the new APK.
Thank you. I missed that.
Multiple APKs offers a simpler user story.
If you say so (besides the other things I didn't quote), I think you probably didn't wrap your head around this issue. Please follow me:
I have n paid customers that bought my current Pro app version.
They are using the feature set X that they've got with the Pro version.
I decide now to implement in-app-purchases to offer feature set X, Y and so on...
Unfortunately, these changes made by app API 7+.
Thus, as you so suggest, I decide to offer multiple APKs.
Now, the API 7+ crowd suddenly gets updated to this new version of my app.
Because they update to the new APK, they LOSE their feature set X. They now need to buy X again (from the in-app-purchase menu). I took from them something they already had, albeit in a "less shiny" way. It's like me saying:
You either pay me again or you lose what you already have.
Do you see the problem now? Do you see why I'm forced to provide a new app? Or am I still not getting what you said (I think not)?
Here is an untried idea for your consideration:
Upgrade your present, pre-in-app-payments app to include a ContentProvider that provides a cryptographic hash that only it knows how to generate in response to a random seed (to prevent replay attacks).
Release your new app that uses in-app payments as a separate APK, and have it check for the existence of the earlier app on the user's system by attempting to access the ContentProvider just described, passing it a random value and confirming that the response is correct. If such a response is received, then the user owns the old app, and you can enable the corresponding features of the old app in the new app without requiring any in-app payments to do so.
Now, if some of your users skip the upgrade to the old app that gives them the new ContentProvider, and go straight to your new app, they'll be dinged for the payments. But they can then upgrade if they like and run the new app again to get validated.
This does address your issue. However, it has issues of its own. So, put it in your tool kit and see if it comes in handy, as is or in combination with something else you may later devise!
You will do yourself a disservice issuing a new app instead of an update without at least considering multiple APKs, because it complicates upgrading your existing paid users.
Suppose you simply update your paid app to API level 7, cut its price to 0 and add In-App Payments. Devices with API level >=7 will be offered an upgrade, while devices with API level <=6 will not be notified, won't see it in Play (Market), and won't be able to reinstall if they uninstall. That would be 'no' to your questions 2 and 3.
But now it is possible to implement multiple APKs:
http://developer.android.com/guide/market/publishing/multiple-apks.html
http://developer.android.com/training/multiple-apks/
Specific to your issue, you can offer multiple APKs based on API level:
http://developer.android.com/training/multiple-apks/api.html
This lets you maintain two versions of the same app, separated by API level. So the answer to your question 1 is, implement multiple APKs per the cited articles.
By publishing a whole new app, your answer to question 2 is 'yes'. By implementing multiple APKs, the answer to question 2 is also 'yes', and your application lineage/upgrade story is a lot simpler from the user's perspective (a bit harder for you technically, easier in the customer service department). Note also that maxSdkVersion is deprecated, so this throws a little bit of a wrench into your proposal to cap the old APK when you issue the new APK.
Likewise with question 3. Either by publishing a new app or implementing multiple APKs, you can keep offering an APK for the legacy API levels that your users can find and install.
Multiple APKs offers a simpler user story. Publishing a new app makes it easier for you to differentiate the apps, if for example you want to say, "Look! Now EXTRA shiny!"
I've just finished making some updates for a company's Android app, only to realize that they no longer have the private key that was used to sign the original release that went to the Android Market. If I understand correctly, this means that these changes can't be released as an update to the original app. I think the best option is to pull the original app from the market (it doesn't have many downloads or reviews) and re-release the app signed with a new key. However, I'm worried that Android Market might not allow an app to be released which is practically identical to an app that has already been released (e.g. same name, same icon, mostly the same functionality, etc.).
Has anyone been in this situation before? Did google allow you to re-release as a separate app to the Android Market?
You are correct in that you will have to release this as a new application with a different package name. You will have to pull the other app from the Market as it will no longer be updateable and your users will have to redownload the new version of the app.
I don't see any reason why Google would have any issues with this, it's a known issue that some developers/companies can come across when they loose their signing key. Also, as far as I know, Google doesn't closely monitor incoming apps unless they are being flagged.
I've seen some apps that have 10 versions of the same app in the Market, just so that they can have more visibility, which is something that I think Google needs to look out for.
If you just forgot password.
https://code.google.com/archive/p/android-keystore-password-recover/
If you replaced the existing key file.
1.Rename your package name.
2.Generate new signed apk but this time keep copy of the key and never lose it if you want to update your existing app.
I had a similar thing happen, and we had to change the package name even after pulling the original application from the market. I assume this is to protect users from 'accidentally' downloading a malicious update to an application they already have.
As of about August of this year (2011), the Android market has had the capability of uploading multiple APK's for the same package name. You should be able to remove the original APK and substitute a new one with the same package name now using that mechanism.
I haven't tried it yet, but we were able to upload multiple copies of our different applications that targeted specific platforms and it worked like a charm.