Now my company wants to update app with significant changes.
In new app version will change absolutely whole design and internal logic (code).
Will the market allow such an application to be released? Wouldn't that be an intellectual property infringement?
I would like to see official links with information about it.
Updating an app and completely replacing everything about it is fine. Sometimes you rewrite apps, that's ok. The only requirement is that the signing key remain the same, and the version code increase.
As for UP infringement- if your company owned the original app, how would that even remotely be IP infringement? You own the rights to the IP, that includes the right to no longer offer it for download, or for you to reuse the name for a new app.
Related
Our Wear OS application, which is not a standalone application (it is a companion app of our smartphone app, it cannot be used without the smartphone app) keeps getting rejected by Google Play Policy team for the following reason : "Your application requires phone interaction for the watch version to function." even if we have clearly explained in our Play Store description that it is not a standalone application and cannot work when the smartphone app is not available.
Our application was previously accepted and published on the Play Store but we suspect a Google policy change even if we haven't found it clearly anywhere (we have only found recommendations which encourage standalone apps).
=> Are not-standalone Wear OS apps still allowed for Play Store submission or must our Wear OS app include at least a standalone feature ?
Thanks in advance for your help.
TLDR for those who don't want to read the whole message: I had to set the following flag in the watch app's manifest to get my watch app approved:
<meta-data
android:name="com.google.android.wearable.standalone"
android:value="false" />
The longer story
I don't believe that what they forced me to do makes any sense. My application is semi-independent according to Google's own documentation:
A watch app can be considered as one of the following:
Completely independent of a phone app Semi-independent (a phone app is
not required and would provide only optional features) Dependent on a
phone app If a watch app is completely independent or
semi-independent, it is in the standalone category. You must indicate
this categorization to the Google Play store by setting the value of
this meta-data element to true:
My app requires an initial initialization of 2FA accounts, which can be done from an Android phone or from an iPhone. In the second case the Android phone is not required. Google requested to write a "disclaimer", which I've added to the app's description, but that didn't have any effect, they continued rejecting the app. I've asked three times about what was wrong with the disclaimer, but the best answer I've got was:
As much as I'd like to help, I’m not able to provide any more detail
or a better answer to your question.
I've asked one more time about what's wrong with the disclaimer, didn't get any answer, set 'standalone' flag to false and got approved two days later.
The problem that Google created for me and my users was that going forward installing the watch app would be possible from an Android phone only and not from a watch directly. It means that iPhone users would either need to find an Android device to install the watch app or to use ADB, and I'm sure, the users will hate me for this change.
Once again, an impression is that Android is on its way to self destruction: new policies break the old apps, support doesn't exist and developers are forced to make changes that make customers unhappy.
It's not the first episode of this stupidly, just recently I had to disable GDrive functionality in my Android app because new policies broke the existing logic that worked for years, and all OAuth 2.0 processes that Google suggested to be compliant with the new policies were not feasible for a small company
Here is a fragment of my comms with Google that fell on their deaf ears
I sell a game on Google Play called Quantum-X. Not many people have bought it so I want to move to an ad-supported model and make it a free download.
But I want to reward the people who did buy the game by disabling advertising. So existing users see no ads, new users see ads. I can store a flag in some obfuscated, device specific way which makes this determination.
But in order to this I need to tell the difference between paying and non paying users.
So how do I do this? I have a few ideas but I don't know if any of them are viable:
The old app wrote some preferences out. I could look for an old preference and set the flag. But this will not work if someone installs the app on a clean device since they won't have that preference. It is also an exploit since anybody could put the old key in to fool my app into disabling advertising.
My pay app currently uses LVL to validate a person's licence. If I make my app free, what happens when I call LVL? Does it respond LICENCED even if a user downloaded it for nothing? If I could tell paid from non-paying users from the response then I know how to set the flag. But LVL is a pain to test since I would have to upload the app, set it to free and then see what difference there is in the result and there may be none.
I could produce one final update of my pay app which sets the flag and asks users to upgrade. Then I could roll out the app free in a month from now. The same problem exists as with 1. that some users may not update or may install onto clean devices.
I could produce two apps on the store. The pay app could be renamed to "Quantum-X legacy" and a new Quantum-X goes in its place which is free. I would update the legacy version to install the flag, but people would have to switch to the new version for continued support. This would work but it's a lot more effort.
None of these are pretty although 2. would be the least amount of work. Has anyone experience of a working solution, or know a some better way of doing this?
EDIT: My intention is now a hybrid and I've begun to do this:
Rename the old app as Quantum-X Legacy and update the description.
The new free version is called Quantum-X. The only fly in the ointment here is that I must update the app package in the manifest to make the two apps distinct.
I intend to put a test into the free version that calls LVL using the old app's key. If this works the way I think it will, it will tell me when a user has bought the old app (since the licence server is being asked about the old app), and I can write out an obfuscated flag somewhere so I don't have to call LVL any more.
Free users carry on but with ads.
I'm up to 3. and this is my intention. If LVL doesn't work, then I might have to put out an update to the legacy version which writes the flag or puts a code out on screen that someone must use to enable adfree when they install the other version.
Is there an elegant way to handle end-of-life scenarios for an app on Google Play?
Suppose I have an app ("A"), and this app is being superseded by a suite ("S") that has all the functionality of that old app. In other words, S will absorb A. I think it makes sense, from a business point of view, to:
Prevent new sales of A, directing all new sales to S.
Keep supporting A with updates and fixes.
I want to know if it's technically possible. Please disregard SDK requirements and user experience and other OT issues, as I'm not considering with that yet (besides, with this I can always gift old customers in case I want to).
Right now, the only way I see to achieve this is to set the price of A so high that users won't buy it. That way I can keep providing updates without increasing its user base (and thus time spent on support etc.).
One very simple approach would be to simply upgrade your old app to have the new functionality of your suite app, and then rename and re-price the "old" app (which is now your suite) to reflect its new status (e.g., add the word "suite" onto the name). So far as Google Play is concerned, it will still be the same app, only "better." You will keep all the credibility gained from installs of the old app (by essentially upgrading the old app). Your old users will be happy because (as you've described it) they will have all of the old app's functionality, plus some additional functionality.
When I say "upgrade," that doesn't mean that you have to start with the old app's code base; you can just create an entirely new project and APK, so long as you use the same package name and upload it to the old app's location on the Google Play store, and so long as functionally it covers all of the bases expected by your existing user base.
Based on your description, I really can't see the down side of this. It may be that by conceiving of this feature superset as a new product rather than as an update you've created a problem that need not exist.
Currently, Google provides no such functionality. Your best route would be to add functionality to app A that allows it to update using your own private servers, then unpublish the app from the market. It really is quite that Google provides extremely limited functionality in the Dev Console. Instead of taxes, they should've added app coupons and private app listings. Oh Google, "driving sales" as always.
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.